TypeScript annoyances: tsc happily uses `import` statements without extensions, automatically resolving to the appropriate .ts file. But then the output JS files don't work, because they don't have extensions. This is apparently WAI?
Conversation
Replying to
The suggested resolution is to use explicit ".js" extensions in the imports, even though the files you are importing are not .js files (yet). 🙄
But then if you try to import the the same files with Jest for tests, they fail because the import extensions don't match the files!
1
1
So I solved this by switching to using vitests, which still uses jest syntax but behaves better with imports. It's working well so far!
But now I'm worried, if someone wants to use my library as part of a TypeScript project that uses Jest or Mocha or something are they just SOL?
1
Or they're forced to use the compiled JS version of the library, which defeats the purpose of me writing in in TypeScript in the first place, because now it would have been better to just write in JS and provide a separate types definitions file.
1
1
Really this is just another variant of a problem as old as software development itself, where development environments that don't match perfectly always cause problems. I guess I just had hoped TypeScript's ecosystem would somehow be better at it than this?
1
1
Replying to
That codebase doesn't happen to be public? I'd be interested in taking a look.
I was confused by this too, because I swear this hasn't been a problem in other projects I've contributed to. The linked issue points at this being a common stumbling point, though. 🤷
2
Show replies
Replying to
Node ESM is particularly pedantic about this despite build tools being indifferent due to the prevalence of compiled/transpiled JS today. I send at least one PR a month to add explicit file exts since it worked for someone in dev but not in prod.
Replying to
This is 100% my biggest grumble with trying to only use tsc for a fun project. Seems like the expectation for any library is to use a bundler so that it arrives via a JS blob in npm and the types arrive separately via npm. Even if the base library is pure TS.
1
1
Replying to
It's frustrating. People having been fighting about this for years. (One of the largest discussions I've seen on github) It makes writing multi-target TS (node, deno, assemblyscript, workers, etc) unnecessarily difficult...
