I know this doesn't directly address your specific scenario, with the '.js' import. But there is a similar situation that got a lot better with TypeScript 5.
For a long time I was annoyed by the similar problem of Deno's requirement for fully-specified import paths like 'foo/bar.ts' making our Deno code not easily interoperable with our "plain-ass TypeScript" code.
We have an Nx monorepo with a large amount of "library" code, which is really just TypeScript code that uses standard TypeScript path aliases[1]. This code is used by various teams for various things, like Node programs, Svelte/Angular/FrameworkOfTheWeek apps, local utilities and built tooling, etc).
However, until recently, none of these libs worked with Deno, because internally they had to import things like 'foo/bar' and not 'foo/bar.ts'. Changing the imports to 'foo/bar.ts' would make them work in Deno, but break them for everything else.
But TypeScript 5 really changed that with the addition of a new config option (discussed here recently[2]):
This lets me take a plain-ass TypeScript Nx monorepo library, and add it to my import_map.json, and use it from Deno code as well. (Nx recently released a new plugin to help with this.)
It's still not ideal, because you have to convert all the files to start importing and exporting using the ".ts" extension, and there are probably edge cases where it breaks something. However, I have been using it since the TypeScript 5 betas and I have not hit any problems yet. (Would be very curious to hear any problems other people have had, though.)
[1]: the entries in the "paths" section of tsconfig.json, which let you map your own import names to filesystem locations, so you can
import { Hoge } from '@acme/hoge';
instead of:
import { Hoge } from '../../../../libs/util/hoge/src/index.ts';
For a long time I was annoyed by the similar problem of Deno's requirement for fully-specified import paths like 'foo/bar.ts' making our Deno code not easily interoperable with our "plain-ass TypeScript" code.
We have an Nx monorepo with a large amount of "library" code, which is really just TypeScript code that uses standard TypeScript path aliases[1]. This code is used by various teams for various things, like Node programs, Svelte/Angular/FrameworkOfTheWeek apps, local utilities and built tooling, etc).
However, until recently, none of these libs worked with Deno, because internally they had to import things like 'foo/bar' and not 'foo/bar.ts'. Changing the imports to 'foo/bar.ts' would make them work in Deno, but break them for everything else.
But TypeScript 5 really changed that with the addition of a new config option (discussed here recently[2]):
This lets me take a plain-ass TypeScript Nx monorepo library, and add it to my import_map.json, and use it from Deno code as well. (Nx recently released a new plugin to help with this.)It's still not ideal, because you have to convert all the files to start importing and exporting using the ".ts" extension, and there are probably edge cases where it breaks something. However, I have been using it since the TypeScript 5 betas and I have not hit any problems yet. (Would be very curious to hear any problems other people have had, though.)
[1]: the entries in the "paths" section of tsconfig.json, which let you map your own import names to filesystem locations, so you can
instead of: [2]: Previous discussion: https://news.ycombinator.com/item?id=35185069#35186448