CJS interop?

[bmeck]

To my understanding this will load CJS files and have named property access on them? There is ongoing discussion if this is going to be implemented or not. I am hesitant to encourage named properties working. In all proposed interopoperability scenarios however, there is a default export that maps directly to module.exports. Something to bear in mind, and perhaps remove named imports until interop is ironed out.

[bmeck]

I bring this up because, whew boy are we in enough of the weeds due to incompatibilities of existing CJS interop w/ babel and ESM

[bmeck]

Example requested by https://twitter.com/dan_abramov/status/806506649544491008

This plugin maps import() to require.ensure()

import returns the ModuleNamespaceObject of an ESM.

require.ensure returns the value of module.exports directly.

CJS interop with ESM cannot create a ModuleNamespaceObject that can proxy to all possible shapes of module.exports.

Due to this all proposals for interop starting with the original EP have used wrapping mechanics to produce ModuleNamespaceObjects. The exact behavior of wrapping mechanics is still in discussion from talks with VM implementors and TC39 started in September. However, all proposals require the wrapping mechanics to provide a default and vary on the behavior of named exports.

A good example of breakage should people expect exact mapping to require.ensure:

(await import('fs')).readFile; // may not work depending on wrapping mechanics

However, if we use the default that exists in all proposals:

(await import('fs')).default.readFile; // will work in all proposals

To note: this is a babel plugin and should detect non-CJS using __esModule on CJS to determine if it is acting as an ESM. If it is acting as an ESM it should be sane to not wrap.

[bmeck]

ah, conversely in the current code:

(await import('fs')).default.readFile;

Does not work, since it doesn't shadow nor wrap default

[Jessidhia]

Sounds like migrating to that is going to be particularly painful for TypeScript... it maps commonjs module.exports directly to the namespace, and requires that you do fun things such as call a namespace import as a function if the commonjs exports was a function, etc...

I think that solution will be a good thing (you can't statically verify the imported symbols otherwise), but sounds like it'll take time 😅

[bmeck]

@Kovensky I've had talks w/ typescript in the past about this, they are aware. This behavior also affects import declarations.

[Jessidhia]

I had actually expected implementers of a dynamic import plugin for webpack to actually map to System.import, which on webpack's implementation should already have the wrap-in-default behavior for non-ESM (...I think). I presume this went with require.ensure for webpack 1 compatibility...

[TheLarkInn]

Yes the import() we have implemented is more similar to System.import

[aluanhaddad]

@Kovensky just in case you were unaware, TypeScript has a flag to model the synthesis of a default export from a CommonJS module. --allowSyntheticDefaultImports

[ljharb]

@bmeck at the moment I'm operating under the assumption/belief/hope that it will indeed allow named property access. Once the interop story gets more concrete, we can ship a breaking change to this transform that implements the proper semantics.

[bmeck]

@ljharb can we at least properly set the default?

[ljharb]

With the way it's implemented right now, won't Babel do the correctish thing wrt default and named exports?