4 ms·

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

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.
  - WorldMaker 3y ago
    CommonJS ("node") resolution was always opt-in in Typescript. Typescript's "classic" resolution, built for AMD, was perfectly capable of working in the browser. Typescript's CommonJS resolution was always fine in Node for ESM when "type": "module". 4.7's new resolution modes/tweaks added support for "mixed-type" packages with plenty of non-.js file extensions, which again were a Node-specific thing, and "idempotent" browser ESM where Typescript does (nearly) no transformations other than type stripping, which is a nice-to-have but not entirely necessary to running in a browser. ("Classic" transformations that assumed ".js" file extensions worked just fine for the browser and work just fine for Node when "type": "module".)
    - Chyzwar 3y ago
      > Typescript's "classic" resolution, built for AMD, was perfectly capable of working in the browser. AMD require RequireJS runtime to work. It is not browser native technology. It is also not ESM. AMD as module systems is dead. > Typescript's CommonJS resolution was always fine in Node for ESM when "type": "module" It was not fine, when you use "type": "module" node.js expect extensions in imports. CommonJS resolution is not compatible with node.js ESM implementation. There is plenty of differences. > 4.7's new resolution modes/tweaks added support for "mixed-type" packages It added support for node.js ESM module resolution, making it possible to write ESM that would work under "type": "module" packages. Just mention that mixed packages are not possible, you cannot require() ESM module and > which again were a Node-specific thing, and "idempotent" browser ESM where Typescript does (nearly) no transformations other than type stripping, which is a nice-to-have but not entirely necessary to running in a browser. In practical terms, any JS project needs to be compatible with node.js. If you want to use ESM it needs to be node.js variant. If you try to use anything other, your tooling would break.

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.
- WorldMaker 3y ago
  CommonJS ("node") resolution was always opt-in in Typescript. Typescript's "classic" resolution, built for AMD, was perfectly capable of working in the browser. Typescript's CommonJS resolution was always fine in Node for ESM when "type": "module". 4.7's new resolution modes/tweaks added support for "mixed-type" packages with plenty of non-.js file extensions, which again were a Node-specific thing, and "idempotent" browser ESM where Typescript does (nearly) no transformations other than type stripping, which is a nice-to-have but not entirely necessary to running in a browser. ("Classic" transformations that assumed ".js" file extensions worked just fine for the browser and work just fine for Node when "type": "module".)
  - Chyzwar 3y ago
    > Typescript's "classic" resolution, built for AMD, was perfectly capable of working in the browser. AMD require RequireJS runtime to work. It is not browser native technology. It is also not ESM. AMD as module systems is dead. > Typescript's CommonJS resolution was always fine in Node for ESM when "type": "module" It was not fine, when you use "type": "module" node.js expect extensions in imports. CommonJS resolution is not compatible with node.js ESM implementation. There is plenty of differences. > 4.7's new resolution modes/tweaks added support for "mixed-type" packages It added support for node.js ESM module resolution, making it possible to write ESM that would work under "type": "module" packages. Just mention that mixed packages are not possible, you cannot require() ESM module and > which again were a Node-specific thing, and "idempotent" browser ESM where Typescript does (nearly) no transformations other than type stripping, which is a nice-to-have but not entirely necessary to running in a browser. In practical terms, any JS project needs to be compatible with node.js. If you want to use ESM it needs to be node.js variant. If you try to use anything other, your tooling would break.