Jest does not work with Firebase out of the box

[levino]

Currently there are ".js" files generated which are "es modules". Since there is no "type": "module" in the package.json, this is simply illegal as far as I can tell. It creates issues when trying to load firebase with jest and jsdom.

Either we have to make this a module or always use .mjs for all modules.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[hsubox76]

If I understand correctly, these rules (the extension must be mjs or there must be type: "module" in the package.json) apply to Node ESM module resolution specifically. In the file you linked above, default is supposed to point to the browser bundle, while we do in fact point to an mjs file for node.import, which should be the relevant case where these rules apply.

I think that Jest/JSDOM runs in Node but for some reason, the build config prefers to pull in the browser bundle. I'm sure there's a reason for this but if the build system is set to follow Node rules there's probably going to be problems if it's pointed at a browser bundle. If there's any way to change the resolver setting in your build config so it prefers the node.import field over the default field, that's probably the best way to solve this. I think that a Node build toolchain expecting Node conventions should be using the Node path and I think it might not be the best idea to change the browser bundle to conform to Node conventions.

[levino]

As far as I understand, jest has its own module resolution and loader. It needs to be able to mock modules, so it needs to somehow overwrite import and require. When the testEnvironment is jsdom, jest mocks a browser environment with window and document etc. So it should be fine to then also "run browser code". This is why jest when run in jsdom-mode will load "browser" files and this is fine. However it does not expect these files to be es modules. It only expects them to be es modules, when they declare, that they are (by the usage of "type": "module") (x)or by declaring it for the files (by giving them the .mjs extension). Is there a place where it says "it is fine to publish an npm package that contains esmodules without setting "type":"module" in the package.json"? I could not find one, but maybe I also overlooked something. Also if we just look at this from the other side: What is the downside of using the .mjs extension as I suggest in #6748 ?

[hsubox76]

Looking around, it seems the .mjs extension causes problems in a number of environments, such as older versions of build tools, or when they are in a project combined with common js dependencies.

The rules cited above (mjs or "type:module") are rules for Node ES modules specifically, not rules for all ES modules. Unfortunately there are is a lot of different build tooling out there for browser bundles and some of it breaks if you don't follow those rules, and some of it breaks if you do.

I'm not sure there is a really good solution to "I want it to resolve following Node rules, but I want the resolved module to behave like browser code" that doesn't break somebody.

I'll try to do some research, if this is very standardized now and there are only a few outliers that would be broken maybe we could make it a breaking change in 10.x similar to us moving to ES2017 as the default bundle in 9.x.

[hsubox76]

Looking more closely, it looks like the @firebase/* packages (@firebase/app, @firebase/auth, etc.) inject a package.json that contains only "{type: module}" into a dist/esm subdirectory where all the esm bundles go and this hasn't been causing any problems for older build tools as far as I can tell.

So we might be able to do the same in the firebase packages. Short explanation: there's a main package, firebase, where all the paths (firebase/app etc.) are just entry points that point to their matching @firebase/* packages. The @firebase packages use the "type:module" trick for all ESM bundles, but the firebase/* entry points don't. Perhaps if Jest/JSDOM and other Nodelike resolvers are getting stuck at the entry point, we can add the same one-line package.json to the entry points and put the ESM files in subdirs.