firebase-tools: Functions not deployed: Typescript build generates incompatible folder structrue

Version info

3.17.4

Platform Information

Windows

Steps to reproduce

Initialize a new project with Angular CLI
Create a new my-interface.ts file at src/app/somefolder/anotherfolder/my-interface.ts
Create sample Interface in my-interface.ts export interface IMySuperInterface { myProperty: string; }
Run firebase init functions and select TypeScript, TSLINT, etc…
Go to functions/src/index.ts and import the created interface import { IMySuperInterface } from '../../src/app/somefolder/anotherfolder/my-interface';
create a sample function and use the created interface somehow.
cd into functions and run npm run build
Run firebase deploy --only functions

Expected behavior

The created function is deployed.

Actual behavior

The created folder structe within the functions/lib is not compatible with the deploy cmd. The transpiled index.js file was created inside a subfolder functions/lib/functions/src.

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 8
Comments: 17 (2 by maintainers)

Commits related to this issue

Migrate ext:info flow to retrieve spec from Registry API (#683) — committed to firebase/firebase-tools by huangjeff5 3 years ago
Migrate extensions commands to use registry APIs (#3273) * Add publisher to registry file fields (#686) * Migrate ext:update ref-based flow to include update warnings + min extension version guard... — committed to firebase/firebase-tools by joehan 3 years ago
Migrate extensions commands to use registry APIs (#3273) * Add publisher to registry file fields (#686) * Migrate ext:update ref-based flow to include update warnings + min extension version guard... — committed to devpeerapong/firebase-tools by joehan 3 years ago

Most upvoted comments

Thanks @yuyinitos , changing from “lib/index.js” to “lib/functions/src/index.js” worked for me.

This bug has been opened for months, and will immediately affect anyone trying to develop firebase functions using typescript.

The firebase init already asks if you are writing the functions for javascript or typescript. It should be simple to generate "main" : "lib/index.js" for javascript and "main": "lib/functions/src/index.js" for typescript.

Please fix it. I’m having second thoughts about using firebase when basic issues like this are not being addressed.

I am seeing this issue on Win 8.1 pro with firebase-tools 6.0.0. Thanks

+23

elebitzero on Oct 28, 2018

I found this too today, importing some types into my functions from a file in my hosting /src folder, which caused it to:

build my Typescript functions into a different folder structure under /lib
not find the new /lib/..../index.jsindex.js
confusingly keep deploying the old /lib/index.js that was still there, but without my changes, and with no errors, everytime I ran firebase deploy --only functions

Once I found it, I could either:

edit "main" in the package.json to point at the new /lib/..../index.js location
remove my imports and rebuild, then it went back to the building it at /lib/index.js

+14

christopherread on Mar 18, 2018

I had similar issues, importing types from outside functions folder worked fine both as relative imports and using typescripts paths to prefix (e.g. "paths": {"@sharedModels/*": ["../src/models/*"]}, if I also had "skipLibCheck": true in tsconfig.json, however (unsurprisingly) this breaks when trying to share actual variable data (in my case a common prefix used in various places).

Currently, the only solution I have is manually copying and pasting shared constants into the functions folder, although I’m wondering if there might be a better fix using typescript project references or similar? Not sure if others have had much success this way?

As for folder structure, the first time I build it generated the nested folder structure and the second time didn’t and I couldn’t recreate… so I’m not quite sure what’s going on there.

chrismclarke on Jun 2, 2020

Edit package.json and change "main": "lib/index.js" to "main": "lib/functions/src/index.js".

yuyinitos on Oct 16, 2018

Hi, just another note to say that I had the same issue because of the same “mistake” (importing types from my main app). I spent a few hours finding out what was the issue… The functions were still running and deploying but without the latest changes I made to some files… I first thought it was a problem with the fact that I was using several .ts files (not just the index.ts which is provided after the init), so I moved all my code into the index.ts and then I found out about this issue and found the reason of this mess !

In the end, I don’t know if wanting to use “external” files (outside of the functions folder) is an error or not, but as it’s not working well, the scripts should at least show a warning somewhere…

websilone on Nov 19, 2019

Thanks for all the thoughts and feedback, we’ve determined this is working as intended and is a result of the nature of Typescript’s ability to import things outside of the obvious source tree (i.e from ../../../something) and there’s not much we can do to improve this experience.

abeisgoat on Jan 24, 2022

Just ran into this problem today. In my previous working codebase, I was unable to add and deploy a new Cloud Function.

changing from “lib/index.js” to “lib/functions/src/index.js” worked for me too.

What makes this issue harder to debug is that terminal output seems to show/infer that the older Cloud functions are getting detected and deployed perfectly implying some issues in the newly written Cloud Function. Would be great if we can solve this one, esp. for those onboarding Typescript.

mayurdhurpate on Jun 24, 2019

I ran into this issue and discovered it was because I was importing an interface from my angular app. The functions folder is its own node environment with it’s own package.json so this must have thrown off the typescript transpiler.

Importing the interfaces from within the functions folder made it so the code transpiled properly.

inorganik on Nov 30, 2018