4 ms·

I think ES Modules are okay frankly. But the current state of the JS industry where everyone is forced to supporting both ES Modules and CommonJS is hellish.

I think ES Modules are okay frankly. But the current state of the JS industry where everyone is forced to supporting both ES Modules and CommonJS is hellish. It is the worst of all worlds. It increases testing surface area, slows down build times, adds complexity. I have wasted many days of time on tooling issues related to this and I am a competent developer. At this point we are too far down the ES Modules path, so let's just commit to it and get this transition over. CommonJS has lost the argument for all practical purposes a long time ago. Could we please forcibly deprecate CommonJS? Lets please only pick one, no more supporting both because they we do not get the benefits of either.

vbezhenar 3y ago
Why would you want to support commonjs? It's some old obsolete thing. Just don't support it.
- davidmurdoch 3y ago
  Because millions of mature packages and libraries already use CommonJS. If we have to rebuild the JavaScript ecosystem from the ground up we might as well do it in a different language.
  - vbezhenar 3y ago
    I recently built react app and everything worked with ESM. Bump major version and that's about it. If someone need to work with old dependencies, they have it.
    - davidmurdoch 3y ago
      Old?
    - TheCoelacanth 3y ago
      Apps are easy. Have you built a library?
      - WorldMaker 3y ago
        In today's supported Node (works just fine in LTS) just "type": "module" in package.json (and learn "exports" for ESM only), never use anything but ESM, and everything mostly "just works" with no CommonJS in sight within your library (other than maybe .cjs config files for slower build/dev time tools like Jest).
- Chyzwar 3y ago
  You cannot, 99% of real life applications is ususing it. Jest only support esm as experimental, typecript added support very recently. Most people use sytax but modules are transpilled to commonjs.
  - vbezhenar 3y ago
    If both library and consumer use esm syntax, why does it matter what code below it's translated to? As long as ESM semantics is preserved, that's just an implementation detail. I have no idea how ESM syntax in my apps works and I hope that I'll never know. It just works.
    - Chyzwar 3y ago
      It matters for things like testing, module resolution and typescript. ESM runtimes are different, most people use ESM syntax with commonjs module resolution (index files, extensionless imports, babel) but this is not compatible with node.js ESM (lack of index files, required file extension) [1] [1] https://nodejs.org/api/esm.html#differences-between-es-modules-and-commonjs https://nodejs.org/api/esm.html#differences-between-es-modul... > I have no idea how ESM syntax in my apps works and I hope that I'll never know. It just works. Once you manage a big enough application, you will know because shit shine through a lot. I spend countless hours to work around ESM issues at work (1mil LoC).
  - WorldMaker 3y ago
    Typescript has just about always supported ESM. (Since way back in 1.x somewhere. I'm too lazy to look up exactly where the line is that you get good ESM modules, but it was very early.) Typescript took a long time supporting Node's wacky multi-file-extension hijinks, but that's mostly on Node. You can make a package.json file with "type": "module" in current Node and use just about any ancient version of Typescript you want to output ESM.
    - Chyzwar 3y ago
      It was supporting ESM syntax with commonjs resolution. Proper support for native ESM was added in 4.7 https://devblogs.microsoft.com/typescript/announcing-typescript-4-7/#esm-nodejs https://devblogs.microsoft.com/typescript/announcing-typescr... Before that it was not possible to write ESM that would work in node.js or browser.

vbezhenar 3y ago

Why would you want to support commonjs? It's some old obsolete thing. Just don't support it.

davidmurdoch 3y ago
Because millions of mature packages and libraries already use CommonJS. If we have to rebuild the JavaScript ecosystem from the ground up we might as well do it in a different language.
- vbezhenar 3y ago
  I recently built react app and everything worked with ESM. Bump major version and that's about it. If someone need to work with old dependencies, they have it.
  - davidmurdoch 3y ago
    Old?
  - TheCoelacanth 3y ago
    Apps are easy. Have you built a library?
    - WorldMaker 3y ago
      In today's supported Node (works just fine in LTS) just "type": "module" in package.json (and learn "exports" for ESM only), never use anything but ESM, and everything mostly "just works" with no CommonJS in sight within your library (other than maybe .cjs config files for slower build/dev time tools like Jest).
Chyzwar 3y ago
You cannot, 99% of real life applications is ususing it. Jest only support esm as experimental, typecript added support very recently. Most people use sytax but modules are transpilled to commonjs.
- vbezhenar 3y ago
  If both library and consumer use esm syntax, why does it matter what code below it's translated to? As long as ESM semantics is preserved, that's just an implementation detail. I have no idea how ESM syntax in my apps works and I hope that I'll never know. It just works.
  - Chyzwar 3y ago
    It matters for things like testing, module resolution and typescript. ESM runtimes are different, most people use ESM syntax with commonjs module resolution (index files, extensionless imports, babel) but this is not compatible with node.js ESM (lack of index files, required file extension) [1] [1] https://nodejs.org/api/esm.html#differences-between-es-modules-and-commonjs https://nodejs.org/api/esm.html#differences-between-es-modul... > I have no idea how ESM syntax in my apps works and I hope that I'll never know. It just works. Once you manage a big enough application, you will know because shit shine through a lot. I spend countless hours to work around ESM issues at work (1mil LoC).
- WorldMaker 3y ago
  Typescript has just about always supported ESM. (Since way back in 1.x somewhere. I'm too lazy to look up exactly where the line is that you get good ESM modules, but it was very early.) Typescript took a long time supporting Node's wacky multi-file-extension hijinks, but that's mostly on Node. You can make a package.json file with "type": "module" in current Node and use just about any ancient version of Typescript you want to output ESM.
  - Chyzwar 3y ago
    It was supporting ESM syntax with commonjs resolution. Proper support for native ESM was added in 4.7 https://devblogs.microsoft.com/typescript/announcing-typescript-4-7/#esm-nodejs https://devblogs.microsoft.com/typescript/announcing-typescr... Before that it was not possible to write ESM that would work in node.js or browser.