Breaking change happened on v8.3.0 (IE 11 support lost)

This package claims to support IE 11 on the readme. But that stopped working on a minor release. From what I can gather, v8.3.0 introduced stringify.js which utilises default parameters. IE 11 does not support default parameters and thus fails.

I’ve managed to fix this issue by using babel, but its worth:

• Not using modern syntax in minor releases until checking they work in all browsers you’re supporting
• Either remove IE 11 support or remove usage of default params
• Using some rollup plugin to compile down to a compatible version

Related to: https://github.com/uuidjs/uuid/issues/469

[ctavan]

In the browser config we can only specify file overrides but not entry points. In order to support all the various platforms that we want to support, the different fields in package.json are crafted the way the are:

• pkg.main is picked up when using the module directly in older Node.js versions. This is the Node.js CommonJS build.
• pkg.module was originally introduced by webpack for being able to ship an ESM build for bundling. In order to allow webpack builds for Node.js, this points to the Node.js ESModule build.
• pkg.browser now defines overrides when bundling for the browser but assumes that browser builds want to use the ESM build. We don’t include a CommonJS build for the browser as we haven’t really come across a use case for that.

So in the specific scenario where you define config.resolve.mainFields = ['browser', 'main', 'module'];, the 'main' and 'module' fields inform webpack about the entrypoint to be used. Since 'main' comes first, webpack will pick the Node.js CommonJS build, and won’t find a browser-specific override.

If you swap the order, then webpack will pick the Node.js ESModule build and subsequently find the corresponding browser-specific overrides and use the Browser-specific ESModule build instead.

So the use case where you instruct webpack to use CommonJS builds instead of ESModule builds is one which we currently do not support.

BTW once you upgrade to webpack@5 this problem will also vanish because webpack@5 uses the definitions from pkg.exports instead.

We could “fix” this by providing a CommonJS Browser build. We have deliberately not done this so far because it would further increase the package size while we are not convinced about any clear benefit this would add.

[jasonwilliams]

my mainfields is set to config.resolve.mainFields = ['browser', 'main', 'module']; which i believe is correct.