3 ms·

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.
    - 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.
  - 3y ago