Allow `rewriteRelativeImportExtensions` to be used with import `paths` aliases

[adamhl8]

🔍 Search Terms

"rewriteRelativeImportExtensions", "paths", "ts 2877"

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Say you have paths set up like so:

"paths": {
  "@/*": ["./src/*"]
}

When rewriteRelativeImportExtensions is true and you use an import alias, you get an error.

import { foo } from "@/my-module.ts"

This import uses a '.ts' extension to resolve to an input TypeScript file, but will not be rewritten during emit because it is not a relative path. (ts 2877)

See my comment here: #61991 (comment)

This error makes sense and I want to be clear about what I'm not suggesting:
- I'm not suggesting that this shouldn't be an error
- I'm not suggesting that TypeScript should rewrite paths aliases

However, there are use cases where the above can be valid. For example, you can use something like justkey007/tsc-alias to rewrite these import aliases after the fact. e.g. tsc && tsc-alias

I have a few ideas on how to allow this:
1. When "moduleResolution": "bundler", this error should not be shown. This seems like the easiest/best fix, although maybe there are situations where this would be bad.
2. Add an option like allowImportingTsExtensionsWIthPaths, but I'm not really a fan of adding a compiler option specifically for this.

Alternatively, maybe this error can just be removed altogether? paths aliases are not rewritten anyway, and tsc will happily compile something with a .js extension like import { foo } from "@/my-module.js", which will not work at runtime.

[RyanCavanaugh]

I don't understand the scenario. If you're using tsc-alias then why wouldn't you set allowImportingTsExtensions?

[adamhl8]

I was typing up a response and realized that the fixes I'm asking for are wrong/backwards. I thought the issue was that TypeScript didn't want to compile because of the paths import specifically, but really it's because TypeScript will only rewrite imports for relative paths (which is exactly what the error says, I just didn't make the connection).

Ultimately the feature request is the same, which is to allow rewriteRelativeImportExtensions to be used with import paths aliases.

The method for doing so would be to have TypeScript rewrite import extensions for relative paths and paths aliases.

To be clear, the following should be a valid tsconfig:

tsconfig.json

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "NodeNext",
    "allowImportingTsExtensions": true,
    "rewriteRelativeImportExtensions": true,
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

And then say we have a file like this:

index.ts

import { foo } from "@/my-module.ts"

Which would be emitted as:

index.js

import { foo } from "@/my-module.js";

Which of course won't work at runtime, but we can fix that using something like tsc-alias.

[RyanCavanaugh]

This is intentionally out of scope, since we don't want to add features that a single-file transpiler would be unable to implement. The problem is that you might have one path mapping that includes *.ts as part of its pattern and one that doesn't, so you would end up in a situation where you have

import foo from "@/bar.ts";
import qua from "@/baz.ts";

where the "correct" emit would be

import foo from "@/bar.js"; // changed
import qua from "@/baz.ts"; // unchanged

depending on what the module resolution results were. That's why the limitation is in place to begin with - it's not that we can't, it's that we shouldn't have behavior like this where the only way for a third party would be to exactly mimic our module resolution behavior.

[adamhl8]

Ah gotcha, thanks. It never occurred to me that you could specify an extension in a path mapping.

Do you think it would make sense then to either:

1. Get rid of that error and simply not rewrite those extensions
2. Provide an option to effectively opt-out of that error (and also not rewrite those extensions)

I think 1 makes sense for a couple of reasons:

• TypeScript already allows you to output "invalid" import/exports (e.g. in other cases it will emit path mappings as-is)
• With the above tsconfig example, an import like import { foo } from "some-node-module/my-module.ts" is currently valid and will be emitted as-is. So this error happens specifically for path mappings.

So emitting non-relative imports as-is, even if they happen to contain path mappings, would make it consistent with extension rewrite behavior for node modules.

This would be a bit of a tsc "gotcha", because you'd have to handle rewriting these extensions after the fact, but I don't think it's any more of a gotcha than the current behavior which emits JS with path mappings.

[RyanCavanaugh]

If you're using path mapping to land on actual .ts files, then AFAICT one of the following is true:

• You have a post-build step to fix the extensions, in which case that step can also handle the relative imports, thus you can safely turn off rewriteRelativeImportExtensions
• You have a TS-aware bundler that makes this whole issue actually irrelevant, again you can safely turn off rewriteRelativeImportExtensions
• You really do have a build problem and this error is legitimate

What's the configuration space where you can't turn off rewriteRelativeImportExtensions but still have a "legal" build?

[adamhl8]

You have a post-build step to fix the extensions, in which case that step can also handle the relative imports, thus you can safely turn off rewriteRelativeImportExtensions

This isn't really possible. If rewriteRelativeImportExtensions is false, TypeScript gives the following error about allowImportingTsExtensions:

Option 'allowImportingTsExtensions' can only be used when either 'noEmit' or 'emitDeclarationOnly' is set. (ts)

Despite what this says, enabling rewriteRelativeImportExtensions is also valid (see #60397).

Point being, you can't emit with allowImportingTsExtensions unless rewriteRelativeImportExtensions is also enabled.

You have a post-build step to fix the extensions, in which case that step can also handle the relative imports, thus you can safely turn off rewriteRelativeImportExtensions

Did you mean extensions and path mappings here? If so, I think this makes sense. i.e. you could have some post-build step that handles transforming path mappings and extensions. But currently you can't get TypeScript to actually emit for this use case.

[RyanCavanaugh]

Yeah, you're right. So the first two bullets collapse into "using an out-of-band bundler/transpiler entirely".

Going back to the original motivation for rewriteRelativeImportExtensions - it's there to support running in a scenario like Node.js's new type-stripping mode, where your code works both before and after the build step. That's not a scenario where path mapping really works in the first place -- only real exports that go through package.json would be supported. Using it in this scenario I would say is just a misconfiguration; you really should just write .js file extensions. I get the aesthetic desire to write .ts instead, but that's not what the flag is actually for.

[adamhl8]

Fair enough, thanks. I appreciate the responses.