4 ms·

TypeScript cannot emit valid ES modules due to file extension issue (2020)

janci 4y ago
This had driven me nuts recently. One of the dependencies was converted to ESM. If I want to import it I must convert my project to ESM (or use dynamic import that is hell of its own). That would not be very painful exept for the need to rewrite every import statement in the project. I guess TS5 with moduleResolution bundler solves that? Did not have time to try that yet.
haburka 4y ago
It’s disgraceful how little respect github commenters have for maintainers sometimes. They seem so entitled to having the package work the way they want it to when it’s used by millions of developers. I feel that the typescript maintainers were incredibly polite here and should have locked the issue much earlier. Open source developers at big companies are often incredibly competent as well as under supported compared with those that work on products that bring in revenue. We don’t also have to emotionally attack them.
- new_user_final 4y ago
  Except Typescript maintainers were arrogant and locking issues for 6 years (as far as I have seen). It's pretty simple to satisfy the millions of developers, just don't suggest stupid workaround and follow the standard.
fabiancook 4y ago
To tackle this, I always needed to write a little script for my TypeScript projects that were all being published as ESM: https://github.com/virtualstate/promise/blob/main/scripts/correct-import-extensions.js https://github.com/virtualstate/promise/blob/main/scripts/co... https://github.com/virtualstate/focus/blob/main/scripts/correct-import-extensions.js https://github.com/virtualstate/focus/blob/main/scripts/corr... https://github.com/virtualstate/navigation/blob/main/scripts/correct-import-extensions.js https://github.com/virtualstate/navigation/blob/main/scripts... This same script was replicated to near every repository I have worked on, including making its way into a few different production services where Node.js + ESM was used for deployment Eventually I had turned into a utility module that could be used wider, which starts to lean into import map generation https://github.com/virtualstate/impack#usage https://github.com/virtualstate/impack#usage You can see it being used here as a function, but can be used as a cli tool too: https://github.com/virtualstate/listen/blob/033bf8effcbde5c825851516bd651fdc1bd13680/scripts/post-build.js#L7-L14 https://github.com/virtualstate/listen/blob/033bf8effcbde5c8...
gnabgib 4y ago
In your tsconfig.json [0]: "moduleResolution": "node16" In your TS files, even if the import is a file with the extension .ts (tsc will handle): import { test } from './importMe.js'; [0]: https://www.typescriptlang.org/tsconfig#moduleResolution https://www.typescriptlang.org/tsconfig#moduleResolution
- wdb 4y ago
  Didn’t they add a new option `allowImportingTsExtensions` to TypeScript 5 that allows you to use `.ts` in imports? I haven’t tried it but that’s what I understood from the blog article
- triyambakam 4y ago
  Heh, I came to write the same thing. It's somewhat annoying but works well.
- ultim8k 4y ago
  It works but every single time I see it, I start swearing.
- noahtallen 4y ago
  Right, this is what people are arguing about in the issue. It’s honestly extraordinarily unintuitive and frustrating, and the team’s arguments are more philosophical than practical (along the lines of “typescript will never deviate from JavaScript language specification”). I’m not very sympathetic since the entire language is incompatible with a JS interpreter, and importing from a file that doesn’t actually exist is really poor DevX. I really wish the TS team had not forced people to decide between ESM (the future of JS modules) or importing files that don’t actually exist everywhere in the codebase.
  - nikeee 4y ago
    I think it's the right solution, though I get that it confuses people. Given that the compiler only erases static type annotations, it should not touch the imports. > entire language is incompatible with a JS interpreter If this proposal will ever be accepted, TS will be (in large parts) valid JS: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
dimitropoulos 4y ago
If anyone is interested in knowing more about module resolution in TypeScript, a friend of mine did a great talk about it [0]. It touches on exactly this topic in the timestamp in the link. [0]: https://youtu.be/MEl2R7mEAP8?t=2360 https://youtu.be/MEl2R7mEAP8?t=2360
crooked-v 4y ago
This reminds me again of the whole mess with `paths` and the TS team refusing to do the bare minimum to make TS->JS compilation work with that feature instead of needing to rely on outside tooling.

This had driven me nuts recently. One of the dependencies was converted to ESM. If I want to import it I must convert my project to ESM (or use dynamic import that is hell of its own). That would not be very painful exept for the need to rewrite every import statement in the project. I guess TS5 with moduleResolution bundler solves that? Did not have time to try that yet.

haburka 4y ago

It’s disgraceful how little respect github commenters have for maintainers sometimes. They seem so entitled to having the package work the way they want it to when it’s used by millions of developers. I feel that the typescript maintainers were incredibly polite here and should have locked the issue much earlier. Open source developers at big companies are often incredibly competent as well as under supported compared with those that work on products that bring in revenue. We don’t also have to emotionally attack them.

new_user_final 4y ago
Except Typescript maintainers were arrogant and locking issues for 6 years (as far as I have seen). It's pretty simple to satisfy the millions of developers, just don't suggest stupid workaround and follow the standard.

fabiancook 4y ago

To tackle this, I always needed to write a little script for my TypeScript projects that were all being published as ESM: https://github.com/virtualstate/promise/blob/main/scripts/correct-import-extensions.js https://github.com/virtualstate/promise/blob/main/scripts/co... https://github.com/virtualstate/focus/blob/main/scripts/correct-import-extensions.js https://github.com/virtualstate/focus/blob/main/scripts/corr... https://github.com/virtualstate/navigation/blob/main/scripts/correct-import-extensions.js https://github.com/virtualstate/navigation/blob/main/scripts... This same script was replicated to near every repository I have worked on, including making its way into a few different production services where Node.js + ESM was used for deployment Eventually I had turned into a utility module that could be used wider, which starts to lean into import map generation https://github.com/virtualstate/impack#usage https://github.com/virtualstate/impack#usage You can see it being used here as a function, but can be used as a cli tool too: https://github.com/virtualstate/listen/blob/033bf8effcbde5c825851516bd651fdc1bd13680/scripts/post-build.js#L7-L14 https://github.com/virtualstate/listen/blob/033bf8effcbde5c8...

gnabgib 4y ago

In your tsconfig.json [0]: "moduleResolution": "node16" In your TS files, even if the import is a file with the extension .ts (tsc will handle): import { test } from './importMe.js'; [0]: https://www.typescriptlang.org/tsconfig#moduleResolution https://www.typescriptlang.org/tsconfig#moduleResolution

wdb 4y ago
Didn’t they add a new option `allowImportingTsExtensions` to TypeScript 5 that allows you to use `.ts` in imports? I haven’t tried it but that’s what I understood from the blog article
triyambakam 4y ago
Heh, I came to write the same thing. It's somewhat annoying but works well.
ultim8k 4y ago
It works but every single time I see it, I start swearing.
noahtallen 4y ago
Right, this is what people are arguing about in the issue. It’s honestly extraordinarily unintuitive and frustrating, and the team’s arguments are more philosophical than practical (along the lines of “typescript will never deviate from JavaScript language specification”). I’m not very sympathetic since the entire language is incompatible with a JS interpreter, and importing from a file that doesn’t actually exist is really poor DevX. I really wish the TS team had not forced people to decide between ESM (the future of JS modules) or importing files that don’t actually exist everywhere in the codebase.
- nikeee 4y ago
  I think it's the right solution, though I get that it confuses people. Given that the compiler only erases static type annotations, it should not touch the imports. > entire language is incompatible with a JS interpreter If this proposal will ever be accepted, TS will be (in large parts) valid JS: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations

dimitropoulos 4y ago

If anyone is interested in knowing more about module resolution in TypeScript, a friend of mine did a great talk about it [0]. It touches on exactly this topic in the timestamp in the link. [0]: https://youtu.be/MEl2R7mEAP8?t=2360 https://youtu.be/MEl2R7mEAP8?t=2360

crooked-v 4y ago

This reminds me again of the whole mess with `paths` and the TS team refusing to do the bare minimum to make TS->JS compilation work with that feature instead of needing to rely on outside tooling.