Allow imports with mapped paths to generate resolved path in require()

[ToddThomson]

I am using an import within a Ts source file:

import { TsCore } from "@TsToolsCommon/Utils/TsCore";

This import gets resolved correctly:

======== Resolving module '@TsToolsCommon/Utils/TsCore' from 'C:/Users/Administrator/Source/Repos/TsTools/Ts2Js/src/TsCompiler.ts'. ========
		Explicitly specified module resolution kind: 'NodeJs'.
		'baseUrl' option is set to 'C:/Users/Administrator/Source/Repos/TsTools/Ts2Js/src', using this value to resolve non-relative module name '@TsToolsCommon/Utils/TsCore'.
		'paths' option is specified, looking for a pattern to match module name '@TsToolsCommon/Utils/TsCore'.
		Module name '@TsToolsCommon/Utils/TsCore', matched pattern '@TsToolsCommon/*'.
		Trying substitution '../../TsToolsCommon/src/*', candidate module location: '../../TsToolsCommon/src/Utils/TsCore'.
		Loading module as file / folder, candidate module location 'C:/Users/Administrator/Source/Repos/TsTools/TsToolsCommon/src/Utils/TsCore', target file type 'TypeScript'.
		File 'C:/Users/Administrator/Source/Repos/TsTools/TsToolsCommon/src/Utils/TsCore.ts' exist - use it as a name resolution result.

In the tsconfig.json, I have:

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

The require() in the compiled js output is:

var TsCore_1 = require("@TsToolsCommon/Utils/TsCore");

I expected that this would be resolved to the full relative path.

This causes grief in mocha test resolution as the "@TsToolsCommon/Utils/TsCore" module cannot be found.

[ToddThomson]

It appears that issue #22908 tracks a similar request.

To be clear: I am only asking for a compiler option to force modules resolved with mapped paths be converted to the full relative path to the module. This would allow compiled code which requires mapped modules to just work. Modules imports resolved with mapped paths are then just a form of short hand.

[MikeMitterer]

I expected that this would be resolved to the full relative path.

@ToddThomson The whole world, except MS, expects a resolved path...
Same problem: #10866

[hdodov]

I have a proposal for this feature. As @DanielRosenwasser said in #10866:

path mapping reflects the behavior of an external resolution scheme (e.g. path mapping in AMD and System.js, aliases in Webpack and other bundlers)

If paths are resolved by TS, the bundler on top of it would get confused since it's expecting an aliased path and isn't getting it. This is obviously a needed feature and the default (current) behavior shouldn't change.

However, resolving those paths has its use cases - basically whenever you don't use a bundler. In my case, I need this functionality even with a bundler - I need tsc to emit all files in a js folder which Webpack watches and then bundles in dist. Reason being - the package is a library and I want its modules to be consumable both separately and as a bundle. Why not use Webpack to deal tsc's job as well? It's a bundler and I don't want the source to be bundled. tsc transpiles src into js, Webpack bundles js into dist. With that setup, however, Webpack needs the resolved paths in js since it works independently from tsc and doesn't know the aliases. Besides, consumers using individual modules from the library (in js) need the resolved paths as well.

Proposal

We can have a compilerOptions.resolveMappedPaths option which is a boolean defaulting to false. This way, people using a bundler let the bundler resolve the aliases by setting it to false. On the other hand, people who don't use a bundler let tsc resolve the aliases by setting it to true. Everybody wins.

[Joelbear5]

I'm really glad this got brought up again after @DanielRosenwasser closed #10866. This is such a simple feature that will help many who aren't using bundlers for application such as nodejs backends. Even if I had a bundler, I would have to tell it what @my-alias even means, and would have to do this anyway.

I'm not sure, though, that I want to resolve all of my tsconfig.json compilerOptions.paths elements. Also, since the paths alias elements takes in a list (e.g. ["./src/*", "./lib/modules/*"]), it cannot resolve multiple path aliases, especially with a wildcard character such as * or ?. Compunding off of what @hdodov mentioned above, here are my proposals.

Proposal 1

Have a compilerOptions.aliasResolvers option that takes in "@my-alias": "path/to/resolve" . This is really a module import string replace. E.g.:

// tsconfig.json
{
    "compilerOptions": {

        "aliasResolvers": {             <=
            "@my-alias": "./src"       <=
        },
        "baseUrl": ".",
        "paths": {
            "@my-alias": ["./src/*"]
        {
    }
}

Proposal 2

Add an optional object type to compilerOptions.paths with resolvesTo option. E.g.:

// tsconfig.json
{
    "compilerOptions": {

        "baseUrl": ".",
        "paths": {
            "@my-alias": {
                "path": "./src/*",
                "resolvesTo": "./src"   <=
             }
        {
    }
}

[Joelbear5]

@DanielRosenwasser Can you please link the duplicate open issue?

[ark120202]

@Joelbear5 #26722