ESM: exports not utilised when importing CJS.

[joeyhub]

Version: v12.10.0
Platform: msdos, x86_16
Subsystem: ESM

Using "type": "module" and an mjs as an entry point, module isn't uses from package.json and when falling back to main (CJS), using purely exports rather than assigning module.exports doesn't appear to work.

Seen when trying to use rollup-plugin-analyzer.

[joeyhub]

Also doesn't work with:

import traverse from "@babel/traverse";

Despite docs using include and despite working for core which looks about the same (strange thing with default being set).

[shobhitchittora]

@joeyhub sorry but I couldn't understand the problem here correctly. Can you share some code sample of your issue here? Thanks.

[joeyhub]

"type": "module",

Just set that in JSON.

Even just running node and then require('@babel/traverse') needs me to do traverse.default.

Both of these libraries do this:

Object.defineProperty(exports, "__esModule", {
  value: true
});
exports.default = some_func;

Both also define the script as the main.

[devsnek]

I'm seeing this, which is the expected output

[joeyhub]

What happens if you:

node --experimental-modules --input-type=module -e 'import traverse from "@babel/traverse";traverse();

I get TypeError: traverse is not a function. It's some weird fallback thing using __esModule that's not coming into play with the ESM for picking up default.

With one case I tried just assigning module.exports instead of just exports.default instead and it worked.

[devsnek]

@joeyhub its not a function, its an object. think of it as export default require('@babel/traverse');

[joeyhub]

According to a google search, I think it's something to do with this:

Something like this was the first hint many of us detected that there was a family of squirrels living under our wallpaper.

Is the __esModule thing an old fallback prior to full ESM support to at least allow require to return a default as well as a nest of object entries?

Did node ever support that or was it something people were doing and introducing an unnecessary transpile pass inadvertently for people that wanted to use the library straight up?

If so do npm packages with an entry point like this need to be pointed out (they should otherwise dist with it compiled properly to cjs/es)?

[devsnek]

__esModule is a nonstandard babel (and later typescript) thing. In real native esm, the exports of a module have to be declared before it is evaluated, so we have no way of mapping cjs exports to esm (and even if we could, i'd still argue that export default require() makes more sense)

[joeyhub]

So basically I need to raise this with the NPM packagers for those libraries to fix their build and maybe push for it to be recognised as a problematic practice.

[devsnek]

i don't have a one-size-fits-all solution, but i will note that require('some babel tool').default has bothered me for years.

[joeyhub]

It's really problematic if you look for example at the babel manual. They have straight up ESM examples with none of that and no impression that you have to babel compile their library before you can use it in the way they specify (otherwise the ugly .default).

Even is packages do use that function, I'm certain they're making a mistake at this point now with proper ESM not compiling fully to a CJS (main, legacy?) and ESM (module) entry point.

If they were giving examples using as though that ESM style hack was in use before but not documenting to do that you need a whole transpile pass then I think they were also making a mistake even then (with a lot of users probably stumbling around to find .default or worse making an unnecessary build of something already meant to be built for you).

If it was never supported by node then it should be gradually purged.

[pand-app]

Hello guys,

@joeyhub Please confirm that issue is the same : https://github.com/Nainterceptor/node-issue-29537 ?

Quick explain :
root has a "type": "module" and is .mjs.
dependency has both cjs and esm (typically like when you have a typescript build).
dependency has main and module keys pointing on cjs and esm parts
root load the cjs part, ignoring "module" key.
If I add "type": "module" in the dependency, app is trying to load the main key (so the cjs script) as an esm module.