3 ms·

It was supporting ESM syntax with commonjs resolution. Proper support for native ESM was added in 4.7 https://devblogs.microsoft.com/typescript/announcing-type

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.
  - WorldMaker 3y ago
    > AMD require RequireJS runtime to work. I said the "classic" resolution was built for AMD, but that it worked just fine for browser-intended ESM. I didn't say to use AMD, I said that ESM has worked for a long time in Typescript, in part because the "classic" resolution has always worked in browsers (whether transpiling to AMD, UMD, or ESM). Maybe you should read my comment again? > It was not fine, when you use "type": "module" node.js expect extensions in imports. Typescript has always included extensions in the output of imports. When you used a bare TS file import without an extension it added a .js extension in the transpiled output. .js file extensions have always worked in Typescript (going back to 0.x days). TS 4.7 added support for .cjs and .mjs, that's the new thing. Versions of Typescript have been just fine with ESM output since 1.x somewhere with the right configuration. You don't need 4.7 to do ESM in Typescript. It helps with some nice-to-haves in Node if for some reason you are trapped into support both .cjs and .mjs files side-by-side in the same library and need all of those to be Typescript, but you don't need it for anything else. Sure, Node compatibility can be important (it just isn't important to Browsers). There's (luckily) no such thing as an "ESM variant" of Node and browsers will never have to know anything about the .mjs file extension. (Web servers will to make sure the present the right mime type, but that's a separate issue.) They just need ESM. I stand by accusing Node of doing the silly thing by adding the .cjs and .mjs file extensions. (I understand why they did it and mixed-module libraries were a thing that needed to exist until LTS support for ESM was well adopted, but we're past that transition phase, it wasn't that long of a transition phase, and in hindsight I think it still feels a little silly. Useful, but silly.) (ETA: I did AMD in Typescript a long time ago. I've done ESM in one form or another in Typescript for many years before TS 4.7. TS 4.7 isn't needed to do ESM in Typescript. I know this from plenty of past experience.)
    - Chyzwar 3y ago
      > Typescript has always included extensions in the output of imports. When you used a bare TS file import without an extension it added a .js extension in the transpiled output. .js file extensions have always worked in Typescript (going back to 0.x days). It was not. https://github.com/microsoft/TypeScript/issues/16577 https://github.com/microsoft/TypeScript/issues/16577 There was proposal and PR, but It was rejected. When writing ESM in typescript, you need to import with .js extension. >There's (luckily) no such thing as an "ESM variant" of Node and browsers will never have to know anything about the .mjs file extension. (Web servers will to make sure the present the right mime type, but that's a separate issue.) They just need ESM. I stand by accusing Node of doing the silly thing by adding the .cjs and .mjs file extensions. (I understand why they did it and mixed-module libraries were a thing that needed to exist until LTS support for ESM was well adopted, but we're past that transition phase, it wasn't that long of a transition phase, and in hindsight I think it still feels a little silly. Useful, but silly.) There is absolutely such thing. Spec is either intentionally not being followed (babel) or it allows for host implementation to define some things (node.js, deno). > but we're past that transition phase, We are not. 99% of new projects use ESM with CommonJS resolution today!. Most codebases have no way to transition to ESM. It was a Herculean effort for typescript codebase to be migrated into ESM https://devblogs.microsoft.com/typescript/typescripts-migration-to-modules/ https://devblogs.microsoft.com/typescript/typescripts-migrat... in March this year!.

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.
- WorldMaker 3y ago
  > AMD require RequireJS runtime to work. I said the "classic" resolution was built for AMD, but that it worked just fine for browser-intended ESM. I didn't say to use AMD, I said that ESM has worked for a long time in Typescript, in part because the "classic" resolution has always worked in browsers (whether transpiling to AMD, UMD, or ESM). Maybe you should read my comment again? > It was not fine, when you use "type": "module" node.js expect extensions in imports. Typescript has always included extensions in the output of imports. When you used a bare TS file import without an extension it added a .js extension in the transpiled output. .js file extensions have always worked in Typescript (going back to 0.x days). TS 4.7 added support for .cjs and .mjs, that's the new thing. Versions of Typescript have been just fine with ESM output since 1.x somewhere with the right configuration. You don't need 4.7 to do ESM in Typescript. It helps with some nice-to-haves in Node if for some reason you are trapped into support both .cjs and .mjs files side-by-side in the same library and need all of those to be Typescript, but you don't need it for anything else. Sure, Node compatibility can be important (it just isn't important to Browsers). There's (luckily) no such thing as an "ESM variant" of Node and browsers will never have to know anything about the .mjs file extension. (Web servers will to make sure the present the right mime type, but that's a separate issue.) They just need ESM. I stand by accusing Node of doing the silly thing by adding the .cjs and .mjs file extensions. (I understand why they did it and mixed-module libraries were a thing that needed to exist until LTS support for ESM was well adopted, but we're past that transition phase, it wasn't that long of a transition phase, and in hindsight I think it still feels a little silly. Useful, but silly.) (ETA: I did AMD in Typescript a long time ago. I've done ESM in one form or another in Typescript for many years before TS 4.7. TS 4.7 isn't needed to do ESM in Typescript. I know this from plenty of past experience.)
  - Chyzwar 3y ago
    > Typescript has always included extensions in the output of imports. When you used a bare TS file import without an extension it added a .js extension in the transpiled output. .js file extensions have always worked in Typescript (going back to 0.x days). It was not. https://github.com/microsoft/TypeScript/issues/16577 https://github.com/microsoft/TypeScript/issues/16577 There was proposal and PR, but It was rejected. When writing ESM in typescript, you need to import with .js extension. >There's (luckily) no such thing as an "ESM variant" of Node and browsers will never have to know anything about the .mjs file extension. (Web servers will to make sure the present the right mime type, but that's a separate issue.) They just need ESM. I stand by accusing Node of doing the silly thing by adding the .cjs and .mjs file extensions. (I understand why they did it and mixed-module libraries were a thing that needed to exist until LTS support for ESM was well adopted, but we're past that transition phase, it wasn't that long of a transition phase, and in hindsight I think it still feels a little silly. Useful, but silly.) There is absolutely such thing. Spec is either intentionally not being followed (babel) or it allows for host implementation to define some things (node.js, deno). > but we're past that transition phase, We are not. 99% of new projects use ESM with CommonJS resolution today!. Most codebases have no way to transition to ESM. It was a Herculean effort for typescript codebase to be migrated into ESM https://devblogs.microsoft.com/typescript/typescripts-migration-to-modules/ https://devblogs.microsoft.com/typescript/typescripts-migrat... in March this year!.