HN Explorer

14 comments

[ 3.4 ms ] story [ 42.5 ms ] thread
gnabgib
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
triyambakam
Heh, I came to write the same thing. It's somewhat annoying but works well.
ultim8k
It works but every single time I see it, I start swearing.
noahtallen
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
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

wdb
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
dimitropoulos
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

crooked-v
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.
janci
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
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
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
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...