Repository navigation
Feature: Named exports when importing CJS #81
Description
Activity
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.
Reacted by A.J. Robertspersonally 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);A very large number of the use cases we've documented require being able to
import 'cjs'andrequire('esm')- that's probably one of the more contentious issues overall, of which "shouldimport '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.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.
I think we should bring this question to TC39.
@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.
- 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> .Reacted by Jordan Harband
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.
Reacted by Anna Henningsen, Geoffrey Booth, Benjamin Gruenbaum and Nick EReacted by Anna HenningsenThat’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?
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
@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).
-
As far as I know the user-land
esmloader 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.82 remaining items
@bmeck yes that is the cost of the approach, that exact execution ordering only breaks down between imports of different module formats, but weighed against an entire ecosystem of expectations it seems a worthwhile one to me.
@guybedford I'm not sure how this is only a specific minority of imports, it affects any import that may change formats over time. And, when that import changes formats it will be hard to debug.
Reacted by Jordan HarbandThe ecosystem also has an expectation - for both require and import - that everything evaluates in lexical order. I think that’s much more important than named imports from CJS (as long as there’s at least default imports of CJS)
Reacted by snekI've yet to see even two CommonJS packages on npm that require exact execution order between them that aren't polyfills - I have personally never written a NodeJS app that had to carefully order require statements apart from dealing with circular references.
Predictable semantics are incredibly important yes, but two-phase execution like this was the original plan for CommonJS laid out by TC39 to begin with through zebra striping. It was never deemed a spec violation then, so I'm not sure why it should be so now.
@guybedford polyfills and circular requires aren't nothing. if your polyfill is written in esm and we do out-of-band you're screwed.
If your npm package requires a polyfill to be used and is written in CommonJS, then yes, you would need your polyfill to be written in CommonJS as well.
I'm not convinced that removing ordering predictability is worth getting named exports when we can just read the properties off a
defaultvalue. That costs the ecosystem just like not having named exports does. However, I value predictability over named exports since I cannot recreate the feature of predictability/debugging as easily as I can recreate the feature of named exports.Reacted by snek and Charles SamborskiIt's not just polyfills; it's anything that sets up state. Bootstrapping react flux stores, connecting to databases, configuring stateful libraries, etc.
Reacted by snekIn the internal loader, do we have access to the names that are being imported?
For example, withimport { default as x, y, z } from 'cjs', that would be['default', 'y', 'z']@targos we do not, and even if we did there are problems with creating module records from them. Particularly if 2 modules have
import {a} from 'cjs';
and
import {b} from 'cjs';
What is the shape of the module that we create? Or what if they don't list the names:
import * as cjs from 'cjs'; const cjs = import('cjs');
@ljharb most packages in the JS ecosystem require a top-level call to start these things. I've never once used a library that did any of that work on top-level execution - please by all means find a counter example though.
Reacted by Charles Samborski and Corentin GirardFor the first case, my idea was to create two different module records. I didn't think about the namespace import. That's a dead-end...
Neophyte chiming in.
I know much less than I wish about modules, but I did manage to publish an ESModule that's backwards-compatible with CJS, by setting
maintoindex(no extension) inpackage.json. Would this method be worth advocating to module authors, as (obviously) an interim and partial solution until this issue reaches consensus and resolution?
Currently in NodeJS, if I import from a CJS module,
It will allow this, but won’t allow named exports, i.e. the following is not allowed:
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:
import.meta.require(or equivalent) to enable importing CJS from ES modules//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.