Feature: Named exports when importing CJS

[giltayar]

Currently in NodeJS, if I import from a CJS module,

import ns from `./cjs-module.js`

It will allow this, but won’t allow named exports, i.e. the following is not allowed:

import {namedSomething} from `./cjs-module.js`.

This is called transparent interop.
The reason that NodeJS doesn’t allow named exports is that determining what those exports are MUST happen in the parsing phase of the ESM Spec (according to some, although there is contention about that too), and executing code is not allowed at or prior to that phase. But a CJS module’s exports can only be determined by evaluating the code in it (static analysis of JS is not an option as it is not determined to always give the correct results).

This would maybe have been cool if NodeJS was the first ESM implementation, but people are used to the babel way of doing modules, and in the babel world, named exports from CJS modules are allowed. This is because babel does not conform to the ESM spec to the letter (it can’t, because it just transpiles ESM to CJS).

And, good or bad, developers expect to use named exports when importing CJS.

I see these options:

1. Continue the existing way (no named exports for CJS)
2. Don’t conform to the spec when importing CJS
3. Do late-linking/shaping of named modules based on late evaluation of CJS module
4. Disallow transparent interop, and enable import.meta.require (or equivalent) to enable importing CJS from ES modules
5. Enable metadata in the CJS module that can statically describe the exports for ESM, e.g. something like //export default; export foo, bar; at the head of the CJS file, thus enabling named exports when importing the file.

I am sure there are others options, so if you have another option besides those four, please add it here.

It would be great if for each options you specify pros and cons, or at least if you don’t like the option, specify a clear and simple use case that would be problematic if the option was chosen.

Edit by @GeoffreyBooth: Use case 12.

[giltayar]

This issue was raised in #80

[GeoffreyBooth]

It’s worth reading the comments in #80 too, especially concerning the observability (or not) of what gets done in the parsing phase.

I would encourage us to try to find a solution that threads the needle if at all possible. This probably isn’t a stark decision between honoring the spec or not. I bet we can find a solution that enables this while still adhering to spec, or adhering to the spec as far as any user-executable code could ever know, or adheres mostly to spec. I think it’s worth exploring the gray area as much as possible.

[devsnek]

personally I'm not a fan of importing cjs at all. (as a bonus we could drop the mjs extension if we didn't support it.) I would prefer something like import { makeRequire } from 'module'; const require = makeRequire(import.meta.url);

[ljharb]

A very large number of the use cases we've documented require being able to import 'cjs' and require('esm') - that's probably one of the more contentious issues overall, of which "should import 'cjs' support named imports" is a small subset.

I think spec compliance is paramount, and I'd love to have import { Children } from 'react', for example, work (where "react" is a CJS module) - but I suspect we'd have to come up with a way to get consensus to change the spec for that to become tenable.

[GeoffreyBooth]

Some of the discussion in #80 revolved around how to define “spec compliance.” If external code can’t see what Node is doing under the hood, and if Node is compliant as far as the external code can detect, than can that be considered “spec compliance”? Because if so, then that’s a way to have it both ways: do whatever parsing or evaluating that needs to be done in the parsing phase, in a non-observable way that has no side effects, and you get the ability to import CommonJS named exports without violating the spec. The trick is figuring out that “non-observable way that has no side effects.” But I think that’s a straightforward engineering problem that can be solved.

[mcollina]

I think we should bring this question to TC39.

[ljharb]

@GeoffreyBooth i believe that it's always possible to write code that observes the ordering of evaluation and linking, which is why it would require a spec change in EcmaScript to have node do that and be compliant.

@mcollina I believe @bmeck has already done so, but if there's new information it might be worth another shot.

[MylesBorins]

I'd be more than happy to help socialize specific ideas at tc39... We will need to be explicit as to what those are though.

…

On Mon, May 14, 2018, 6:07 PM Jordan Harband ***@***.***> wrote: @GeoffreyBooth <https://github.com/GeoffreyBooth> i believe that it's always possible to write code that observes the ordering of evaluation and linking, which is why it would require a spec change in EcmaScript to have node do that and be compliant. @mcollina <https://github.com/mcollina> I believe @bmeck <https://github.com/bmeck> has already done so, but if there's new information it might be worth another shot. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#81 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV0UD0kdh16r_1W09WMupZkL1p8hsks5tygANgaJpZM4T-eT5> .

[jdalton]

I'm cool having CJS evaluate before resolving named exports. It's what we're doing for builtins modules today (with the assumption errors/side-effects won't happen during evaluation). For the broader case, of more than just builtin modules, if errors do happen during evaluation I don't find the difference that ghastly, since that is something CJS users expect. The concern is scoped to CJS interop, so isn't something that bleeds into browser interop scenario, and can be something that is opted-in-or-out of as needed without broader approval from others like the TC39.

[GeoffreyBooth]

That’s another good point—could we do this evaluation during the parsing phase for CommonJS imports only? Because the spec doesn’t concern itself with CommonJS, right? So however Node wants to handle CommonJS is up to us, so long as we follow spec with regard to true ES modules?

[devsnek]

i actually proposed this way back in my first pr (nodejs/node#16675) and TC39 discussed it here: https://github.com/rwaldron/tc39-notes/blob/master/es8/2017-11/nov-28.md#9iie-discuss-module-order-instantiationevaluation-guarantees

its worth noting that (afaik, please correct me if i'm wrong) source text refers to whatever the original thing is that rules what is exposed from the import, which is in this case the cjs

[bmeck]

@GeoffreyBooth there have been a variety of approaches implemented and or looked at but they seem to fall into 3 real areas of investigation.

• loader, docs, test: named exports from commonjs modules node#16675 which did out of order evaluation.

• https://github.com/bmeck/node/tree/named-export-core did pre-parsing to form the shape instead of evaluation.

• https://github.com/rwaldron/tc39-notes/blob/master/es7/2016-09/sept-28.md#es-modules-lifecycle discussed late linking (shape of dependencies not verified until evaluation reached).

[jdalton]

As far as I know the user-land esm loader works with named exports of CJS modules in ESM without order of evaluation issues or pre-parsing CJS export pragmas (named-export-core). This means that the root issue may be something deeper like being able to perform creation, instantiation, and evaluation phases synchronously.