Minimum to release?

[GeoffreyBooth]

In your opinion, what needs to be added to the minimal kernel/new ecmascript-modules implementation (and/or the implementation that Guy has built atop that), in order to:

• Replace the current --experimental-modules with the new implementation?
• Unflag the new implementation?

With “the new implementation” here meaning, the new ecmascript-modules implementation plus whatever features you consider must-haves for either of the above milestones. What’s your “release as flagged” minimum viable product, and your “release as unflagged” minimum viable product?

[ljharb]

To unflag (not exhaustive):
Must have: Transparent interop
Should have: transparent interop by default

[guybedford]

@ljharb can you clarify what you mean by transparent interop? Because all the current implemetations support importing CJS from ESM with ESM syntax.

[ljharb]

Fair point :-) one way to describe the “levels” of interop, as i see it, is:

1. can import both named and default from cjs into esm without any change to the cjs, and without knowing that the module is cjs
2. the current dynamic modules proposal, which allows the above except for export * from cjs during a cycle
3. the first one, minus named
4. any of the above, but you have to know it’s cjs
5. no interop, except by custom loaders, some of which ship with node
6. no interop, except by userland loaders

I see each one as strictly better than the one that follows it, and i think that while the first is the ideal, shipping the second is far superior to any of the others.

[robpalme]

These levels make sense to me.

My view is that we could ship without interop altogether (level 7?) and still get high adoption over the long-term. But we should have higher ambitions.

The sweet spot of reconciling what is best for our users whilst still being implementable/acceptable looks like level 3. It means named imports become a progressive enhancement you can use in your package as and when your dependencies upgrade to ESM. That matches the mental model of named exports being a value-add feature of introducing ESM in the first place.

[guybedford]

@ljharb thanks for expressing your preference, in that case lets see if we can keep dynamic modules moving forward. But as mentioned previously, if we don't get them, then I think we have to go back to (1) and shouldn't let this bump cause reconsideration of the entire approach.

[ljharb]

@robpalme i don’t think that’s how users will view it; many are already using named imports via babel or esm (and in tons of docs and tutorials) and without them in node, our implementation will be seen as lacking features, not adding them.

[MylesBorins]

I think people can recognize the difference between using tools and core platform. If our loaders implementation allows next generation tools to accomplish this people will use it, or alternatively augment their code. I don't think this is so black and white though... We can also ship something and incrementally improve it over time

…

On Tue, Jan 22, 2019, 10:25 AM Jordan Harband ***@***.***> wrote: @robpalme <https://github.com/robpalme> i don’t think that’s how users will view it; many are already using named imports via babel or esm (and in tons of docs and tutorials) and without them in node, our implementation will be seen as lacking features, not adding them. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#253 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV7cPx40QZa5AGiyj_rdYG1J6cYP5ks5vFy2DgaJpZM4aLo_B> .

[zenparsing]

I think we are also underestimating the people-power of the ecosystem to adapt to no-cjs-imports. All it takes to add import support to any package is a simple PR adding an ESM entry point (or points) which maps CJS names to ESM names.

Here's one such PR I just received over the weekend, unsolicited:

zenparsing/zen-observable#55

[ljharb]

It seems like that’s a smaller underestimation then underestimating the people-power of the ecosystem to adapt to the incredibly rare “export * from cjs when inside a cycle” case.

[zenparsing]

To clarify, it's not just the cycle case where dynamic modules disallows "export * from cjs".

Also, there was no claim made with regard to the ecosystem adapting to the lack of certain module features when importing CJS. Rather, the claim was that the lack of certain features will likely be perceived as a bug without any simple explanation as to why it doesn't work.

[GeoffreyBooth]

Folks, do you mind keeping the export * discussion in its own thread? In this one, please just answer the questions in the original post.

@ljharb, is there anything more than interoperability that you would want to see in the new implementation before it’s released flagged or unflagged? Loaders? Same goes for @guybedford @zenparsing @MylesBorins @robpalme

[ljharb]

I also want extension and index resolution, just like CJS has.

[devsnek]

I also consider this incomplete without extension/index resolution. Same with loaders.

[robpalme]

@ljharb @devsnek Please could you confirm if your extensionless/index requirement is satisfied by the web-compatible approach of solving this for bare specifiers? That is the problem we have work in-flight to solve in the form of Jan's pkg-exports

@devsnek Please could you clarify which loader hooks must exist before we unflag. Also, given our working group explicitly prioritised fixed-functionality (phase 2) over extensibility (phase 3), what would be the reasoning for needing loaders from day 1?