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.
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
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
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 everyimportstatement in the project.
I guess TS5 with moduleResolution bundler solves that? Did not have time to try that yet.
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.
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.