FR: provide a "modern" ESM build without jsbi

[taralx]

There's a babel plug-in for it, but it would be nice to have a ready-to-import version.

[12wrigja]

#138 (comment) seems related.

For your use-case, are you planning on using this polyfill:

• only within applications (that don't themselves become NPM packages) and can made the decision whether they need JSBI
• only within an ecosystem of packages where native BigInt is considered available on the platform?

Are you aware of any other packages that have this sort of a problem and how they went about solving it? I'm not opposed to having a solution, but I'd prefer not to create a bifurcation in the ecosystem where there are some packages using this dependency assuming that native BigInt is available only to find that someone who wants to depend on those needs JSBI.

Would it work for your use-case to have JSBI defer to native BigInt if available, but still pay the code-size cost of JSBI itself? This used to be a feature in JSBI but was removed.

[taralx]

I'm using it on browser, where we expect all users to have bigint (we need newer features anyway). Having it defer would be ok, but we're trying to keep download sizes down as well, preferably without introducing an additional transpile step.

[taralx]

If you prefer not to create a third output (.bigint.mjs), then what about just applying this to the ESM output? Anyone who is worried about older platforms like that is going to be using CJS anyway.

[12wrigja]

I'd probably lean towards making more outputs that are listed as conditional exports (https://nodejs.org/api/packages.html#conditional-exports) and could be imported like so:

import {Temporal} from '@js-temporal/polyfill/bigint';

Or some such.

I don't want to tie this to the module system used as it can be quite surprising which tools chose to use what thing we specify in package.json (see #29 for example).

[12wrigja]

Though I think this strategy will lead to weird bifurcation issues within the ecosystem and likely weird issues if both versions are in use at once (besides the expected doubled code-size).

[12wrigja]

trying to keep download sizes down as well, preferably without introducing an additional transpile step.

To be clear: have you tried the Babel plugin and does it meet your needs besides having another build step?

[taralx]

I haven't tried it but it almost certainly works. It's just that right now we don't have a transpile requirement, and I was hoping to keep it that way. 🙂

[12wrigja]

Would you mind describing your current dev & prod build setups in more detail? I'd like to understand why adding a transpilation step here is something you want to avoid. I can generally understand the desire to have fewer tools/processes in place, but any general solution to the bifurcation problem I presented above likely requires ecosystem-wide tooling support. If your goal is to reduce download code-size then I'd have thought you would already have transpilation / minification in place for prod builds.

[taralx]

Right now it's all just direct <script> tags from unpkg. No build steps at all.

[taralx]

You're right, we're probably going to need to set up a build at some point. I was just thinking maybe others might want the same thing here. But I also understand the fragmentation / too many artifacts argument.

[12wrigja]

Thanks for your understanding. It's less about the number of artifacts and more about fragmentation / confusing problems stemming from using two copies of the Temporal source simultaneously.

That being said, this discussion is making me reconsider attempting upstream adjustments for JSBI to use native BigInt where available so that whilst code-size might suffer more the runtime performance should improve for most users.

[jimmywarting]

👍 would also want a scaled down version. don't care about IE anymore. all the new browser have auto updates and have had BigInt for a while now.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt#browser_compatibility

[12wrigja]

webpack/webpack#15903

I've filed this issue against Webpack to consider what it would take to have support in bundler tools for the sorts of conditions we would need to make this "automatic".

If we generated a build that only ever uses native bigint and referenced it in package.json using a custom condition, would that be enough? I'm concerned that won't be compatible with the various build tools that people use, and that configuring it would be just as difficult as installing and using the JSBI Babel plugin).

If something like this ends up working, perhaps we can flip the defaults (so by default users use a build that uses native bigints, and you have to opt in to using JSBI if your build needs it).

[taralx]

That's a great idea, but probably needs to be up a level at the package manager, i.e. npm/yarn/etc. rather than at the bundler level.