In the meantime I started contemplating - for v3 - to drop support for umd modules altogether:

#646 (comment)

We shouldn’t even need CommonJS modules, given the lib isn’t supposed to and will just not work in a node environment. To make this explicit, we have chosen to use the browser field for the npm package.

Didn’t think through all the implications of dropping support for cjs yet, certainly it would require ES modules aware bundlers, which I‘m fine for v3. For everything else there would always be v2.

I think I'd agree on dropping UMD. AMD/RequireJS seems thoroughly dead and probably not worth serving anymore.

I do very much disagree on CommonJS. Native ESM module are still in its infancy in many ways. I think it's premature to abandon CommonJS. For example, we had to disable loading ESMs in Webpack because some packages released ESM modules incompatible with the CommonJS modules in the same package which broke either the web build or the Node.js process. Rollup makes it pretty painless to support both and while the number of special case package.json fields is rather annoying it does create a very seamless experience.

So how could a solution look like when dropping support for amd, i.e. umd? We'd have to start providing an iife variant to be used for users not using a bundler (realistic?) and in order to solve #646.

Ideally I'm thinking we'd have three variants (iife -> dist/js.cookie.js, esm -> dist/js.cookie.mjs, cmd -> dist/js.cookie.cjs):

"browser": "dist/js.cookie.js"
"exports": {
  "import": "dist/js.cookie.mjs",
  "require": "dist/js.cookie.cjs"
}

(or main instead of browser if latter poses an issue with bundlers)

Hmmm, no longer building a umd variant we'd loose noConflict() which apparently people are using: #580 (I guess when referencing the file directly from cdns). Not sure whether this would be an acceptable breaking change for v3, but I'm thinking it's not.

I'm so confused: #646 (comment)

Thanks @realityking 😍

@realityking Let‘s say I need to add another iife variant for dist, is there a predefined/recommended setup for package.json?

(Needed to close #646)

Thanks for merging! I don't fully understand your question. What variant are you trying to add?

We can try this again without breaking jsdelivr 😬

I didn’t realize people were so frequently deep linking to a specific build file and don’t pin to specific versions. How annoying (and what an anti pattern when packages can declare which files are to be used for jsdeliver).

Two options:

1. Maintain B/C bu using a slightly different naming scheme so that the UMD files keep their existing names.
2. Avoid using the old UMD names altogether and force break this entirely to make people learn.

Just kidding about 2. I’ll make a PR for approach 1 this weekend.

Unfortunately we (the maintainers) created this problem ourselves, by advertising the deep link in the readme: dd1699f

Despite prominent note (never prominent enough) I believe many developers are quickly copy&pasting the link from the readme in master, ending up with a release candidate. 💥

I have removed the example altogether now, you get more convenient copy&paste links on jsdelivr anyway.

Thanks for creating another PR. I've been thinking about the support for older Node.js versions (the cjs format that was added to rollup) - which node versions are these? I'm not too keen on having this, to me the browser field really makes sense for this library. E.g. it would be acceptable for me to restrict it to newer versions for a v3 release. On the other hand, I experienced myself that Webpack requires some extra config to disrespect the browser field, and that's also not ideal.. a bit torn here.

// make webpack skip package.json “browser” field
module.exports = {
  resolve: {
    mainFields: ['module', 'main']
  }
}

EDIT: Thought: maybe by now Webpack looks for module first by default?