I saw that the TS team was also considering using a runtime helper to replace the extension in cases where the specifier is not statically analyzable. We should consider doing something like that.

a might not be a string -- in that case we need to do String(a) first.

I think a + "" should align to the ToString AO better than String(), since String(symbol) will return its description while ToString(symbol) is a type error.

This could probably be shorter:

return String(source).replace(/([\\/].*\.[mc]?)tsx?$/, "$1js");

and it becomes short enough that we could even just inline it in the code without a helper, so we don't have the problem of it not being available.

Here, it is not sufficient to detect the bare import; consider @foo/bar.ts .

That might need to be rewritten, if for example you are remapping

<script type="importmap">
  {
    "imports": {
      "@components/": "./ui/components"
    }
  }
</script>

We added the exception for "it needs to have a slash" because:

• there are known npm packages with no scope that end in .ts
• if you use import maps and have no slash, it means you are explicitly writing the import specifier in your import map

So far nobody ever reported a problem with the @foo/bar.ts handling, but if there is a package out there needing it the only way forward is to provide a function option in the config once somebody needs it.