https://nodejs.org/api/packages.html#dual-package-hazard
Publishing packages with dual CommonJS and ESM sources, while has the benefits of supporting both CJS consumers and ESM-only platforms, is known to cause problems because Node.js might load both versions. Example:
<table><tr> <th><code>package.json</code></th> <th><code>foo.cjs</code></th> <th><code>foo.mjs</code></th> </tr> <tr><td>{
"name": "foo",
"exports": {
"require": "./foo.cjs",
"import": "./foo.mjs"
}
}
</td><td>
exports.object = {};
</td><td>
export const object = {};
</td></tr></table>
<table><tr>
<th><code>package.json</code></th>
<th><code>bar.js</code></th>
</tr>
<tr><td>
{
"name": "bar",
"main": "./bar.js"
}
</td><td>
const foo = require("foo");
exports.object = foo.object;
</td></tr></table>
// my app
import { object as fooObj } from "foo";
import { object as barObj } from "bar";
console.log(fooObj === barObj); // false?????
The two suggested solutions boil down to "even when you have an ESM entrypoint, still use only CJS internallly". This solves the dual package hazard, but completely defeats the cross-platform benefits of dual modules.
If foo instead used these export conditions:
{
"name": "foo",
"exports": {
"node": "./foo.cjs",
"default": "./foo.mjs"
}
}
Then:
node version (if they are configured to target Node.js) or the default version (if they are configured to target other platforms).We have been using this node/default pattern in @babel/runtime for a couple years, because we wanted to provide an ESM-only version for browsers while still avoiding the dual-package hazard (@babel/runtime is mostly stateless, but @babel/runtime/helpers/temporalUndefined relies on object identity of an object defined in a separate file).