[Feature Request] Resolve alias path to relative path.

[fenying]

Search Terms

resolve path map

Suggestion

I think, there is two way to resolve the path:

1. Add an option to force TS compiler transform import path in the output.
2. Use a plugin (which described in 3.6 plan TypeScript 3.6 Iteration Plan #31639 ) to transform the path in the output.

Use Cases

I've read some rejected FEATURE REQUEST like: #10866 #9910 #5039

And there is , maybe, the official response about those request: #9910 (comment)

However that can not convince me, because of following 2 problems

1. Like the above issues mentioned, it doesn't transform the path aliases into the real relative paths.

   This makes the output not work with Node.js because it can not find the modules by an alias path.

   Although some module like module-alias, ts-alias-loader could solve this, anyway it's not elegent, and it can not solve the second problem.

2. If a package insides node_modules, written in TS with paths options, its alias path in *.d.ts can not be resolved. And TS compiler will throw an error because the module couldn't be resolved.

Examples

See #10866

Checklist

My suggestion meets these guidelines:

• 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, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[RyanCavanaugh]

There's a problem: Sometimes the paths on disk during build time are not same as the paths at runtime. What should be done about it?

There are two reasonable ways to go about solving this situation.

The first is to have you always write the path to the file on disk, and provide a way for you to specify how the compile-time path should turn into a run-time path.

The second is to have you always write the run-time path, and provide a way for you to specify how run-time paths map to disk paths during compile-time.

These are roughly equivalently good; we've chosen the second one because it's easier to "get right" and plays better with ignoring unresolved modules. In either case, you end up with an enormously complex system; the complete documentation of how to control everything here is probably tens of pages.

The third option is to offer both. This is basically taking an enormously complex system and then squaring the complexity. I think it's an understatement to call this complete insanity; no one would be able to successfully reason about this beyond the most trivial of configurations.

We're always open to more options about how to be more expressive in the space of the chosen option of "always write the runtime path"; any suggestions need to be in that realm.

[georgyfarniev]

Well, I read a lot of threads about same issue and I generally agree that good solution could be providing rich extensions api for typescript that allows such behavior.

[icopp]

For me, the biggest hole with paths functionality is the complete lack of functionality around .d.ts files.

If I have a Node module written in Typescript, I can use a bundler to compile it to JS with mapped paths... but the only way I have to do the same for .d.ts files is to do some kind of awful hacky regex thing on the exported files after tsc runs.