Feature: No refactoring #87
Description
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 import and export statements 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 .mjs extension for our import statements 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 import and export statements, and has for years—you just need to use Babel (or esm etc.). 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 .gitignored dist folders 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.