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

[gamsterx]

Version info

3.17.4

Platform Information

Windows

Steps to reproduce

1. Initialize a new project with Angular CLI
2. Create a new my-interface.ts file at src/app/somefolder/anotherfolder/my-interface.ts
3. Create sample Interface in my-interface.ts
export interface IMySuperInterface { myProperty: string; }
4. Run firebase init functions and select TypeScript, TSLINT, etc...
5. Go to functions/src/index.ts and import the created interface import { IMySuperInterface } from '../../src/app/somefolder/anotherfolder/my-interface';
6. create a sample function and use the created interface somehow.
7. cd into functions and run npm run build
8. 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.

[tinaliang]

Could you try importing the interface with import { IMySuperInterface } from '../../src/app/somefolder/anotherfolder/my-interface' and let me know if that works for you?

[gamsterx]

Sorry that was how i actually imported it (I´ll edit the repo steps)...

The folder structure after npm run build looks like this:

• /lib/functions/src/index.js //<--- new transpiled index.ts with new code after the interface import

• /lib/functions/src/index.js.map

• /lib/src/app/somefolder/anotherfolder/IMySuperInterface.js

• /lib/src/app/somefolder/anotherfolder/IMySuperInterface.js.map

• /lib/index.js //<--- old transpiled index.ts with old code before the interface import, which gets deployed

• /lib/index.js.map

[christopherread]

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

[christopherread]

One possible improvement suggestion: before a new Typescript build, automatically clear out the /lib folder under /functions

[yuyinitos]

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

[elebitzero]

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

[inorganik]

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.

[acegreen]

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 I have the same issue, can you elaborate on this? Do you mean just changing the import statement to point to the lib/... directory?

[inorganik]

@acegreen make sure you aren't importing any interfaces, services, etc from your angular app or outside of the functions directory. Only import from within the functions folder or node modules. If you need the same interface - dupe it inside the functions directory and import it from there.

[acegreen]

@inorganik duplicate it really? When importing from an outside app, it seems the compiler creates a lib/scr/app/... for those interfaces. Can I just point to that translated version?

[mayurdhurpate]

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.

[somervda]

Just a note that I ran into the same problem for the same reason (referencing models from my main app). It is really tough to diagnose because deploy still says it is working and it is not obvious this is caused by a code change in the functions. BTW: I decided to create a local copy of the main app models rather than use the new lib structure, I'll see if I regret it :) .

[websilone]

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...

[chrismclarke]

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.