Thanks for the 0.900.16

[akauppi]

..and first impressions.

Still no exports

I noticed the build is picking up "dist/esm5", instead of "dist/esm2017" (the latest tech?). There is still no "exports" field (just saying).

The real fix:

• just rename "esm2017" keys in package.json to "exports". This seems to work. Is "esm2017" a Firebase specific convention?

Workaround:

• in Vite config, I can set resolve.mainFields: ["esm2017"]. This does the trick, but feels a bit wrong.

extractQuerystring is not found

This is an obvious packaging bug, but I found a way around it:

Error: Build failed with 1 error:
[init] node_modules/@firebase/auth/dist/esm5/index-232c6c32.js:3:153: error: No matching export for import "extractQuerystring"
[init]     at failureErrorWithLog (/Users/asko/Git/GroundLevel-es-firebase/packages/app/node_modules/esbuild/lib/main.js:1177:15)
[init]     at buildResponseToResult (/Users/asko/Git/GroundLevel-es-firebase/packages/app/node_modules/esbuild/lib/main.js:913:32)
[init]     at /Users/asko/Git/GroundLevel-es-firebase/packages/app/node_modules/esbuild/lib/main.js:1008:20
[init]     at /Users/asko/Git/GroundLevel-es-firebase/packages/app/node_modules/esbuild/lib/main.js:559:9
[init]     at handleIncomingPacket (/Users/asko/Git/GroundLevel-es-firebase/packages/app/node_modules/esbuild/lib/main.js:648:9)
[init]     at Socket.readFromStdout (/Users/asko/Git/GroundLevel-es-firebase/packages/app/node_modules/esbuild/lib/main.js:526:7)
[init]     at Socket.emit (node:events:378:20)
[init]     at addChunk (node:internal/streams/readable:313:12)
[init]     at readableAddChunk (node:internal/streams/readable:288:9)
[init]     at Socket.Readable.push (node:internal/streams/readable:227:10)

It seems @firebase/utils must have renamed extractQuerystring to querystring but @firebase/auth wasn't updated, accordingly.

Workaround:

• edit node_modules/@firebase/auth/dist/esm2017/index-2cb9d3c8.js and
• add "querystring as" before "extractQuerystring"

Works for me.

System:
macOS, node 15.x, Vite 2.0.5 for packaging

[retronav]

Thank you team for releasing v0.900.16! I was waiting for it since days.
I'm here to confirm that I have been facing the same issue of "'extractQuerystring' is not exported by node_modules@firebase\util\dist\index.esm.js, imported by node_modules@firebase\auth\dist\esm5\index-232c6c32.js"

[Feiyang1]

'extractQuerystring' is not exported issue has been fixed in v0.900.17. Sorry for the broken build!

[Feiyang1]

I'm still debating which build we should provide by default (es5 or es2017). I'm a little concerned if we provide the es2017 build as the default (pointed by module and browser fields), we will force people to compile our code if they want to target older browsers, which I think some folks consider as an anti-pattern (having to compile library code from node_modules).

Or maybe we can point module and browser to the es2017 build and create a new esm5 field that points to the es5 build, which people can use to target older browsers without compiling our code?

@davideast @jamesdaniels Any thoughts on the default build format?

[Feiyang1]

I'm looking into the exports support - I thought it's only useful for Nodejs, but it seems you can use the browser condition to define entry points for bundlers as well, but how do you provide multiple build targets for an entry point? Maybe using the same module, browser fields nested under browser?

Also how good is the bundler support? By looking at rollup/plugins#208, it doesn't seem rollup supports it yet and if it does, it will still check module first before looking at exports. So is there any real benefits of using exports for browser usage?

[akauppi]

I may be biased and ahead of the curve, since I only use exports, and only use ES modules. But it is a standard and will rule over the other ones, in a while.

how do you provide multiple build targets for an entry point?

I do it like this (link):

"exports": {
    "./cjs": "./src/cjs/index.cjs",
    "./cloudFunctions": "./src/cloudFunctions/fns.js",
    "./firestore": "./src/firestore/index.js",
    "./firestoreReadOnly": "./src/firestoreReadOnly/index.js",
    "./jest": "./src/jest/eventually.js"
  }

The ./cjs is what is exposed to CommonJS usage. It can expose a whole separate build. Granted - the consumer needs to know this, i.e. importing the right kind of package becomes explicit instead of implicit (based on the logic of the builder). This may be a good thing?

ie. if I want to use the CommonJS part, it's `import "firebase-jest-testing/cjs".

[akauppi]

Rollup handles module resolves via @rollup/plugin-node-resolve plugin. Its web page states:

This plugin supports the package entrypoints feature from node js, specified in the exports or imports field of a package. [...] This is the default behavior. In the abscence of these fields, the fields in mainFields will be the ones to be used.