Cannot start firebase emulator functions with node 14. ES Module import failure on windows.

[paulvanj]

I am getting the following error:

i  emulators: Starting emulators: auth, functions, firestore, hosting, storage
!  functions: The following emulators are not running, calls to these services from the Functions emulator will affect production: database, pubsub
+  functions: Using node@14 from host.
i  firestore: Firestore Emulator logging to firestore-debug.log
i  hosting: Serving hosting files from: dist/apps/public-client
+  hosting: Local server: http://localhost:5005
i  ui: Emulator UI logging to ui-debug.log
i  functions: Watching "D:\Github\ros-firebase\dist\libs\cloud-functions" for Cloud Functions...
!  functions: Only file and data URLs are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'd:'
!  Your function was killed because it raised an unhandled error.

Is there anything I can do from my side to solve this problem, or am I forced to use commonjs as long as I am developing on windows? (I do not like the idea of adding simport throughout the entire dependency chain of my cloud-functions code.)

Originally posted by @DibyodyutiMondal in #2994 (comment)

[taeold]

I have a proposed fix on branch dl-cf3-esm-windows. Can someone help me confirm the fix on windows?

> git clone https://github.com/firebase/firebase-tools.git
> cd firebase-tools
> git checkout origin/dl-cf3-esm-windows 
> npm i
> npm run build
> npm link # firebase cli should now point to locally built one
# cd to your functions project
> firebase functions:shell

[paulvanj]

I have a proposed fix on branch dl-cf3-esm-windows. Can someone help me confirm the fix on windows?

> git clone https://github.com/firebase/firebase-tools.git
> cd firebase-tools
> git checkout origin/dl-cf3-esm-windows 
> npm i
> npm run build
> npm link # firebase cli should now point to locally built one
# cd to your functions project
> firebase functions:shell

Thanks, gave it a try and it produced the following error(see attached)... although the file does exist.

> firebase "functions:shell"

!  functions: Cannot find module 'C:\...\functions\lib\utils\setup' imported from C:\...\functions\lib\index.js
!  Your function was killed because it raised an unhandled error.

I am using Nodejs 14.17.3, tsconfig is set for es2020 with package.json's type as "module"

[DibyodyutiMondal]

This looks like the same result I got when I tried to use pathToUrl by editing the firebase-tools files inside of node_modules..

Is this the same? If so, I can attest, that it did not work in my case, either.

[DibyodyutiMondal]

I think it is not working because the import statements do not have the .js extension, as they are coming from typescript.
Added problems when we use json files with typscript via the resolveJsonModule typescript option

Manually going and adding .js to the transpiled files, solves the 'cannot find module' error, but results in:

 Named export 'initializeApp' not found. The requested module 'firebase-admin' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'firebase-admin';
const { initializeApp } = pkg;

!  Your function was killed because it raised an unhandled error.

Using webpack too resulted in an error: exports is not defined, although I am inclined to think that is an issue with webpack and es6, not firebase. At any rate, my knowledge of webpack is extremely limited, so I could not explore further.

[taeold]

@paulvanj You may already know now, but you need to include .js extension when importing from local modules:

// BAD
import Setup from './utils/setup' 
// GOOD
import Setup from './utils/setup.js' 

@DibyodyutiMondal Curious, are you required to use ES module in your setup? In most cases, you would setup in tsconfig.json , module: commonjs and move along, but it sounds like you want to package your function definitions as a ES module. Can you share what you are trying to achieve?

(I'm closing the issue, as I think the reported issue is now answered. Feel free to re-open if you are still having a problem @paulvanj ).

[taeold]

Oops. I forgot that the original issue is still unfixed in the main branch. I'll get a PR setup and actually release a fix before closing the issue.

[DibyodyutiMondal]

Well, you are right - since I am using Typescript anyway, from a development perspective, I don't need to worry if the transpiled cloud-functions code is commonjs or esm. However, the cloud-functions code references libraries containing data models and the like, that are also used by my front-end angular app.

Since functions-framework can only load commonjs, these libraries must also be in commonjs, which then results in angular not being able to tree-shake them, increasing the size of the website distribution.

Hence my high preference to be able to use esm.

(Also, being able to use top-level await to perform some of the setup actions is going to be cool for code ergonomics, but it's not as much a pain point as the bloating libraries issue)

[taeold]

@DibyodyutiMondal Thanks for sharing your setup. It sounds advanced, and I'm glad to have a chance to learn how functions is being used by our advanced users.

It sounds like using Typescript (along with Webpaxk) with ES module is a tricky business, and I'm not too familiar with these techs to offer useful advice 😢. I am personally curious and going to try different setups to see if we can come up with a good starting template. Would appreciate if you can share what you learn from your setup.

[DibyodyutiMondal]

Sure, I would love to do that. Is there a designated place for that already, or I can just do that here?

Right now, the best solution I can come up off the top of my head is that any libraries built for both web and cloud-functions must be compiled twice (once for esm, once for commonjs) and then the results be bundled together, so consumers can choose the version they need. As for the 'how' to do that - I too will have to experiment.

[taeold]

@DibyodyutiMondal This is probably a good place to start. Once we have some concrete patterns and recommendations we can suggest, I will work with our DevRel team to find a good place to share the content so other users can learn from it.

Again, thanks for being on the bleeding edge and being proactive about your issues.