Let's start with parse-goals: in JS (from ES2015 onward), a JS file is parsed and evaluated differently if it's a 'script' (this is all parsing pre-ESM) or a 'module' (i.e. an ES module, not a CJS). Note that NodeJS parses CJS modules as 'script', and this is unchangeable, as it would be a major breaking change.

Unfortunately, TC39 did not specify a way of saying what the parse goal of a file is. The browser world decided on two simple rule: 1. if the <script> has a type=module attribute, then it's a module, otherwise it's a script, and 2. if a file was import-ed by another module, then it is a module too.

This means that, in browsers, it is the "importer" that decides the parse goal of the file.

NodeJS decided differently: the parse goal of a file is decided by its extension: .js for script (i.e. a CJS module) and .mjs for ES modules. An interesting proposal to make it out of band in another way (i.e. a mode=esm in package.json is also floating around). All proposals of pre-parsing the file to determine what the parse goal is were rejected (e.g. "use module", or assuming it's a module if there's an export or import statement). Funnily enough, some babel contributors, it seem, agree that the file extension should be the way to determine parse-goals: https://twitter.com/loganfsmyth/status/996088384182411264.

What has this got to do with transparent interop? If we keep the transparent interop, then the runtime, when import-ing the file, needs to determine whether the parse goal is script or module, and thus needs the current mechanism, i.e. the mjs/cjs split. This necessarily precludes working the browser way, which is having the importer determine the parse goal.

You can't have it both ways. Either have transparent interop and force the mjs/js file extension split (which many people don't like), or don't have transparent interop, and have the ability for the importer to determine whether the file is a module or script.

That's one reason for people to dislike transparent interop. The other reason is this: why would we need transparent interop? If we had a meta.import.require that enables ESM to require CJS, we wouldn't really need transparent interop. Except that the babel world works this way. And if we want existing babel code to work transparently, we need transparent interop. This everyone agrees.

But, unfortunately, if we stick to the letter of the spec, we can only default import from a CJS (because determining named exports MUST occur before evaluating the code, and figuring out the named exports can only occur after code evaluation in CJS). And if we have only default imports from CJS, we're anyway not babel compatible.

So if we don't have babel compatibility, why would we need to have transparent interop?

Those are the two reasons I know of.

Uh oh!

transparent-or-not interop #90

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions