TypeScript cannot emit valid ES modules due to file extension issue (2020) | Hacker News Reader

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

github.com

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.

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.

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/co...

https://github.com/virtualstate/focus/blob/main/scripts/corr...

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

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/033bf8effcbde5c8...

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

Heh, I came to write the same thing. It's somewhat annoying but works well.

It works but every single time I see it, I start swearing.

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.

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

Tell that to enums

As of 5.0 you can now use `--moduleResolution bundler` which may solve the main complaints from the issue (I admit I only skimmed it).

[0] https://devblogs.microsoft.com/typescript/announcing-typescr...

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

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.

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

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.

Reply on news.ycombinator.com