fix: provide browser versions independent from module system

[TrySound]

Probably will fix #378

Currently main field is used for node and module for browser build. This
is not entierly correct. Webpack can be used to build node apps. Though
module is always preferred over main. For browser versions there is a
special field.

In this diff I added esm support for both node and browser.
rollup-plugin-node-resolve look at browser field as well and prefer it
to bundle umd.

[ctavan]

@TrySound thank you for working on this, in general the proposed changes look

Using webpack/rollup to bundle for Node.js was indeed not considered yet from our part.

In fact we did use the browser field in package.json in the previous version of UUID and it looks like it is the only way to solve the issues around #378.

It would be great if you could amend the commit message and add references to the documentation of webpack and rollup where the precise usage of the browser fields is documented, I believe that would be:

• https://webpack.js.org/configuration/resolve/#resolvemainfields
• https://github.com/rollup/plugins/tree/master/packages/node-resolve#browser

[ctavan]

Transpile ESM versions of files for use with module bundlers as we do not yet support native Node.js esmodules.

[TrySound]

We should support bundlers with node target.

[ctavan]

The point that I wanted to make is that this is still designated for module bundlers and not https://nodejs.org/api/esm.html

[ctavan]

So: I agree we should not restrict this to browser but the esm build here is still targeted at module bundlers!

[TrySound]

Yes, though commonjs browser stuff can be used by browserify unless it supports modules too.

[ctavan]

Also, please rebase as master has changed meanwhile.

[TrySound]

@ctavan Added links to commit message. Tests look unstable, not related to my changes.

[ctavan]

@TrySound the code looks good, the build errors are due to lacking Browserstack credentials from your fork. I still have to figure out how to proceed with that.

[ctavan]

@TrySound I tried out your changes locally and while they seem fine for use with module bundlers they unfortunately break the native browser esmodule support that is showcased in https://github.com/uuidjs/uuid/blob/master/examples/browser-esmodules/example.js

I fear we may have to go back to two builds:

./dist/esm-node/
./dist/esm-browser/

in order to support esmodules natively in both the browser and (eventually) node without bundlers. What do you think?

[TrySound]

You mean changed paths is breaking change?

[TrySound]

Ah, got it. Browsers do not get right paths.

[TrySound]

Ok, I can do it.

[ctavan]

No: The thing is that so far we only had one esm build designated at the browser where the browser-specific files have been renamed to just replace the node-specific files. That way, you could use the ESM build directly in the browser.

With your change, you rely on the browser field in package.json which is respected by all relevant bundlers but browsers with native esmodules support don't care about that.

So unfortunately your change breaks the opportunity to use esmodules directly in the browser as shown in the example: https://github.com/uuidjs/uuid/blob/master/examples/browser-esmodules/

Since we don't have the nice workaround of relying on the browsers field we may need to build two separate esmodule variants: one that can natively be consumed by the browser and one that can natively be consumed by node. We can then still make use of the browser field in package.json in order to point module bundlers to the correct files for all environments.

[TrySound]

@ctavan Looks good now?

[ctavan]

Looks good now! Will pull this in and add some minor nits on top.