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.<p>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.
To tackle this, I always needed to write a little script for my TypeScript projects that were all being published as ESM:<p><a href="https://github.com/virtualstate/promise/blob/main/scripts/correct-import-extensions.js">https://github.com/virtualstate/promise/blob/main/scripts/co...</a><p><a href="https://github.com/virtualstate/focus/blob/main/scripts/correct-import-extensions.js">https://github.com/virtualstate/focus/blob/main/scripts/corr...</a><p><a href="https://github.com/virtualstate/navigation/blob/main/scripts/correct-import-extensions.js">https://github.com/virtualstate/navigation/blob/main/scripts...</a><p>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<p>Eventually I had turned into a utility module that could be used wider, which starts to lean into import map generation<p><a href="https://github.com/virtualstate/impack#usage">https://github.com/virtualstate/impack#usage</a><p>You can see it being used here as a function, but can be used as a cli tool too:<p><a href="https://github.com/virtualstate/listen/blob/033bf8effcbde5c825851516bd651fdc1bd13680/scripts/post-build.js#L7-L14">https://github.com/virtualstate/listen/blob/033bf8effcbde5c8...</a>
In your tsconfig.json [0]:<p><pre><code> "moduleResolution": "node16"
</code></pre>
In your TS files, even if the import is a file with the extension .ts (tsc will handle):<p><pre><code> import { test } from './importMe.js';
</code></pre>
[0]: <a href="https://www.typescriptlang.org/tsconfig#moduleResolution" rel="nofollow">https://www.typescriptlang.org/tsconfig#moduleResolution</a>
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 <i>every</i> <i>import</i> <i>statement</i> 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].<p>It touches on exactly this topic in the timestamp in the link.<p>[0]: <a href="https://youtu.be/MEl2R7mEAP8?t=2360" rel="nofollow">https://youtu.be/MEl2R7mEAP8?t=2360</a>
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.