Feature: No refactoring #87
Comments
|
Just so we're clear - this means code that uses ESM syntax through a transpiler should keep working without said transpiler eventually? I'd love this - but we need to address the late binding issue somehow and currently babel transpiled ESM code gives you named exports for all cjs. Does this mean that you believe we should do that? |
|
@benjamingr as @GeoffreyBooth hints at, this desire to require 0 change is fairly comprehensive. It deals with cache strategies, disambiguation mechanisms, module shapes, etc. I think we would need to discuss a lot of things regarding those. I'm not sure that this is a single feature exactly since it is so all encompassing and somewhat vague in terms of what is required to create the feature. Truly creating this feature would just be shipping a transpiler from the ESM Syntax to various existing forms instead of using native ESM stuff. I'm not sure how to really approach this issue and converse over it, because I do think it would be ideal. However, I do see some issues with the language of it currently. Namely:
Assumes that transpilers have always been following the rules and semantics of ESM for whatever their output is. I think this is not true in a variety of ways and is not a valid conclusion of what happens from the goals provided. Providing the behavior of a transpiler that does not always match the specification is tantamount just shipping a runtime transpiler. If we do that, we don't even need to address spec or binding issues since we won't be compiling to/from ESM. We will just be reusing the syntax. |
@benjamingr Well . . . why not? What's the advantage for users in not supporting what they're already used to? Like I said, if we can't get there then we can't get there, but shouldn't this be our goal? Every other ES6+ feature that Node has supported has started life as a Babel transform, then users turned off that transform and their code continued to work. @bmeck Babel isn't just some userland thing with no relationship to the spec. The process for getting new ECMAScript syntax approved includes creating a Babel transform or polyfill for the new syntax. That transform therefore is at least an artifact of the standardization process, if not part of the spec itself (as a working prototype for runtimes to emulate). It's not unreasonable for people to think that a Babel transform for a TC39 feature behaves according to the TC39-approved spec for that feature. And following from that, if my code works in that transform it should work in a runtime that implements that transform's feature. Again, I'm not pushing an implementation here. Maybe vanilla Node supports import/export statements only in an all-ESM environment, and mixing in CommonJS involves adding a loader or configuring legacy/interop mode or something like that, whatever people feel comfortable with. But providing users with a way to preserve their current experience without a build step should be part of our scope. We shouldn't ship something less and then punt to userland to figure the rest out. |
|
@bmeck thanks for that, I feel strongly about actually doing ESM rather than "reusing the syntax" while I also want to provide late bindings for CJS. I do like your metadata solution for named exports (and the one Myles presented in #82 (comment) ). It's also worth stating clearly that these goals (browser compatibility, works with native addons and late binding) are at odds by definition. I believe strongly that users should have a way to opt out of things that won't work when they try to run their code in a non-node environment. The migration path for users can also be done with cooperation and coordination of the webpack babel and TypeScript teams who can provide one time transforms for the correct named export semantic and deprecate the non ESM behavior from their end. For example one thing we can consider for the 99% case is testing a tool that converts CJS to ESM automatically for those projects so that we don't have late bindings to begin with. |
Well yes, and we do have two things that are at odds here that are both important - we want to ship ESM with ESM semantics and we want users to not have to use a tool to transpile their existing code. Without metadata (and maybe a tool generating it) or specifying multiple loaders (which would still mean they use babel or std/esm just not webpack) I'm not sure how that can be done. |
|
I'm 100% in support of aligning with the spec, but there are a handful of
things that are supported by transpilers that are not standard including
* Bare imports
* Synchronus loading
* Loading common js
* Loading other non standard goals (html, css, wasn't)
* Using node specific apis from the iife such as
- require
- __dirname
- __filename
- module
While "no refactoring" is an important goal it is important to recognize
that we will need to draw a line somewhere, and that some people may need
to refactor to use whatever default loader we ship
Due to this I think support for custom loaders with a clear and minimal ux
is the solution most likely to be successful.
…On Fri, May 18, 2018, 11:44 AM Benjamin Gruenbaum ***@***.***> wrote:
@bmeck <https://github.com/bmeck> thanks for that, I feel strongly about
actually doing ESM rather than "reusing the syntax" while I also want to
provide late bindings for CJS.
I do like your metadata solution for named exports (and the one Myles
presented in #82 (comment)
<#82 (comment)> ).
It's also worth stating clearly that these goals (browser compatibility,
works with native addons and late binding) are at odds by definition. I
believe strongly that users should have a way to opt out of things that
won't work when they try to run their code in a non-node environment.
The migration path for users can also be done with cooperation and
coordination of the webpack babel and TypeScript teams who can provide one
time transforms for the correct named export semantic and deprecate the non
ESM behavior from their end. For example one thing we can consider for the
99% case is testing a tool that converts CJS to ESM automatically for those
projects so that we don't have late bindings to begin with.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#87 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAecV1I_72BsEd-gfSAedwCf0fm0Dudeks5tzux2gaJpZM4UEN5W>
.
|
See @GeoffreyBooth's opening comment
So there's agreement :) |
|
Ahhh I missed that.
😇
My apologies
…On Fri, May 18, 2018, 12:07 PM John-David Dalton ***@***.***> wrote:
@MylesBorins <https://github.com/MylesBorins>
and that some people may need
to refactor to use whatever default loader we ship
Due to this I think support for custom loaders with a clear and minimal ux
is the solution most likely to be successful.
See @GeoffreyBooth <https://github.com/GeoffreyBooth>' opening comment
The actual way to achieve this ultimately doesn’t matter. If vanilla Node
does one thing but a loader plugin enables “legacy” mode, that’s fine.
So there's agreement :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#87 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAecV8Nx-wb7cs1sOybsRdE7mHfLnKEBks5tzvHKgaJpZM4UEN5W>
.
|
|
Yes, that’s why I’m so excited by the loader plugin proposal: it can bridge these gaps. I would add that we shouldn’t stop at just shipping support for loaders, but also make one or more of our own, to handle all the interoperability and Babel backward compatibility concerns we can think of. Shipping these loaders at the same time as modules support, even if the loaders are just other modules installed via NPM, will hopefully forestall user backlash. And the process of creating loaders for all these use cases will toughen up the loader implementation itself, as we may have to tweak it so that loaders can be created to handle all these cases. |
|
If we enable a pluggable loader for "legacy mode" (synchronous loading in primis), I think we can just be non-compatible from the start. The net result would be that everybody will use a custom loader that is non-compliant, creating the same problem we want to avoid (Node.js running a flavoured version of ESM). |
|
The legacy loader that was pitched in the other issue was about specifier
resolution not about synchronus loading fwiw.
…On Fri, May 18, 2018, 12:50 PM Matteo Collina ***@***.***> wrote:
If we enable a pluggable loader for "legacy mode" (synchronous loading in
primis), I think we can just be non-compatible from the start. The net
result would be that *everybody* will use a custom loader that is
non-compliant, creating the same problem we want to avoid (Node.js running
a flavoured version of ESM).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#87 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAecV8brkjSdL-IE8uKH6e9kuXllwFInks5tzvvpgaJpZM4UEN5W>
.
|
|
was there ever consensus reached about what to do with magic variables in esm mode? |
|
hopefully no one is in favour of them 🤞 |
In the vein of “fast is my favorite feature,” I want to propose a feature that I consider important:
Existing code written using standard ES2015 syntax should continue to work without refactoring, without requiring a separate transpilation build step.
We may not produce an implementation that honors this 100%, but I think it’s important that we get as close as we possibly can. For most users, the only “spec” they’re aware of is ES2015+ and JavaScript syntax generally, and they’ve been told how to write
importandexportstatements a certain way since 2014. If Node’s implementation doesn’t run code written “according to the spec,” this will feel like a breaking change to users, and many will argue that Node isn’t following the spec. They might not be correct, in many members’ view, but there’s a lot of logic to such an argument and it would be very harmful to adoption. It’s in the same vein as the uproar over.mjs; nowhere back in 2014 were we told that we would need to use the.mjsextension for ourimportstatements to work, so therefore Node isn’t honoring the implicit usability contract that a standardized syntax is supposed to provide between users and a programming language: follow these rules, and the language will behave as it’s defined to.The actual way to achieve this ultimately doesn’t matter. If vanilla Node does one thing but a loader plugin enables “legacy” mode, that’s fine. As long as the last four years’ worth of projects that use what was publicized as the “correct” ES2015 module syntax continue to work without refactoring, or with very minimal refactoring, this goal will be achieved.
Some might say, well, if users want their old code to work they should just keep using Babel. But by that logic, Node already supports
importandexportstatements, and has for years—you just need to use Babel (oresmetc.). The whole point of “native” support is so that users can simplify or eliminate their build chains, to avoid the need for transpilation build steps and.gitignoreddistfolders and so on. Part of the reason for JavaScript’s explosive popularity is that it’s platform-agnostic and requires no compilation, and the need for transpilers in recent years has been a drag against JavaScript’s appeal. Put simply, transpilers are what users have now. The point of our work is to give them something better.Use cases 40, 42, 43, 44, 48, and probably others.
This thread could become a catchall for any difficult-to-achieve feature, from #81 to plenty we haven’t discussed yet, so if people don’t mind could we discuss specific things like named exports in their own threads? And this one can stay more general.
The text was updated successfully, but these errors were encountered: