3 ms·
> 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
by 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!.