While ESM support has been stable in current versions of Node.js 14.x and 16.x, support for importing JSON files is still experimental and evolving.
Since we still want to cover the fact that the package is exporting it's package.json file, this test is now extracted to only run with the updated JSON import syntax which requires import assertions and which was introduced in Node.js 16.14.0.
Fixes#619
Co-authored-by: Robert Kieffer <[email protected]>
The new APIs were still missing from some environment-specific tests. We
should definitely consider consolidating these environment-specific test
cases somehow, this currently requires way too much manual work and it's
too easy to miss certain places that need an update.
It appears that react-native and some bundlers rely on being able to
introspect the package.json file of a npm module. After adding the
`exports` field to package.json, only the paths defined in that field
are accessible to Node.js. In order to support introspection of the
package.json file itself it has to be listed as an export as well (see:
https://github.com/ai/nanoevents/issues/44#issuecomment-602010343).
It is currently being discussed to change Node.js' behavior again, see:
https://github.com/nodejs/node/issues/33460
Until then, adding package.json to the exports field should result in
minimum breakage.
Fixes#444
BREAKING CHANGE: Native ES Modules is still an experimental API in
Node.js 14.0.0 and has so far not officially been supported by the
`uuid` module.
Since Node.js allows importing CommonJS modules it was possible to
import the `uuid` module like this:
```js
import uuid from 'uuid';
console.log(uuid.v4()); // -> 'cd6c3b08-0adc-4f4b-a6ef-36087a1c9869'
```
This will no longer work with proper ES Module exports in place. You
can now import the `uuid` library as described in the documentation:
```js
import { v4 as uuidv4 } from 'uuid';
uuidv4(); // ⇨ '9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d'
```
or
```js
import * as uuid from 'uuid';
console.log(uuid.v4()); // -> 'cd6c3b08-0adc-4f4b-a6ef-36087a1c9869'
```
Enabling native ES Modules for Node.js requires some special care for
the v1 algorithm which needs internal state. This makes this library
susceptible to the dual package hazard described in
https://nodejs.org/docs/latest-v14.x/api/esm.html#esm_dual_commonjs_es_module_packages
While the "isolated state" solution seems to make more sense it causes
trouble with rollup which supports CommonJS files only with an
additional plugin, see https://github.com/rollup/rollup/issues/3514.
It is worth noting that webpack could deal with the "isolated state"
solution since webpack supports CommonJS sources out of the box without
further plugins and also doesn't get confused by `.cjs` file extensions
that would have to be used in the state isolation approach for
compatibility with Node.js.
The wrapper approach should however work fine. Here's what code will be
used in each case:
1. Node.js `require('uuid')`
-> dist/index.js (CommonJS) -> dist/v1.js (CommonJS)
2. Node.js `import { v1 as uuidv1 } from 'uuid'`
-> wrapper.mjs (ESM) -> dist/v1.js (CommonJS)
3. rollup/webpack (targeting Node.js environments)
-> dist/esm-node/index.js (ESM) -> dist/esm-node/v1.js (ESM)
4. rollup/webpack (targeting Browser environments)
-> dist/esm-browser/index.js (ESM) -> dist/esm-browser/v1.js (ESM)
Fixes#245Fixes#419Fixes#342
