Add a resolveImportPaths option that resolves import paths configured in paths options

[funkydev]

Suggestion

Add a resolveImportPaths option that resolves import paths configured in paths options,

While transpiling code into the outDir using tsc -p ./tsconfig.json

✅ 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 feature would agree with the rest of TypeScript's Design Goals
  • Align with current and future ECMAScript proposals.
  • Be a cross-platform development tool.

📃 Example

1. Project structure
2. Steps to reproduce
3. Actual result
4. Expected result

Project structure

dist
src
  |- common
  |  |- value-objects.ts
  |- some
     |- extra
        |- nested
          |- folder
            |- greeting.builder.ts
package.json
package-lock.json
tsconfig.json

Source of the package.json file:

{
  "name": "demo-for-typescript",
  "version": "1.0.0",
  "scripts": {
    "build": "tsc -p ./tsconfig.json",
    "start": "node ./dist/some/extra/nested/folder/greeting.builder.js",
  },
  "dependencies": {
    "typescript": "^4.4.3"
  },
  "devDependencies": {
    "@types/node": "^16.9.1"
  }
}

Source of the tsconfig.json file:

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es2017",
    "outDir": "dist",
    "baseUrl": "src",
    "paths": {
      "@common/*": ["common/*"]
    },
  }
}

Source of the src/common/value-objects.ts file:

export class DescriptionValueObject {
  constructor(value: any) {
    if (typeof value !== 'string') {
      throw new Error('Description value has to be of type string');
    }
  }
}

Source of the src/some/extra/nested/folder/greeting.builder.ts file:

import { GreetingValueObject } from "@common/value-objects";
// using paths instead of: import { GreetingValueObject } from "../../../../common/value-objects";
// not only for esthetic purposes, but it helps to resolve conflicts after move files and helps to maintain the large codebase

class GreetingBuilder {
  private name: string;

  withName(name: string) {
    this.name = name;
    return this;
  }

  build(): GreetingValueObject {
    if (!this.name) {
      throw new Error('Set name first!')
    }

    return new GreetingValueObject(`Greetings, ${ this.name }!`);
  }
}

Steps to reproduce

1. Run npm install (tested on npm@7.6.0 and node@15.11.0)
2. Run npm run build (it runs tsc -p ./tsconfig.json script)
3. Run npm start (it runs node ./dist/some/extra/nested/folder/greeting.builder.js file and simulates server-side run)

Actual results

Node returns an error because tsc didn't resolve paths configured in the tsconfig.json for server-side script:

Error: Cannot find module '@common/value-objects'
Source of the ./dist/some/extra/nested/folder/greeting.builder.js:

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
const value_objects_1 = require("@common/value-objects"); // <-- server side script does not understand it
// ... other transpiled code

Expected result

tsc should provide the resolveImportPaths option for developers to choose if transpiler should resolve paths using the provided paths configuration

1. When the resolveImportPaths option was set as true, tsc should emit code with relative paths.

   For this example the require statement should look like: require("../../../../common/value-objects")

   "use strict";
   Object.defineProperty(exports, "__esModule", { value: true });
   const value_objects_1 = require("../../../../common/value-objects");
   // ... other transpiled code

2. When the resolveImportPaths option was set as false (by default), tsc should emit code as it does now

💻 Use Cases

Before you decline this request, you have to differentiate two different scenarios of using typescript:

1. For transpiling client-side apps (like react, angular):
   Understandably, you won't support such an option for this case because paths are mainly used for combining external libraries.

   In this scenario, other tools (like webpack or babel), which are already used in the project, could resolve such mappings and serve correct modules.

2. For transpiling server-side node apps:
   It is needed to have such an option because developers (as many of them showed you in other Issues) don't want to use other heavy tools only for resolving paths in the imports. That's overkill for the thing that should be handled by the transpiler.

   The worst thing after you declined many of previous requests for such options, is that the developers started to use scripts for resolving imports in node.js, that override the private API of the built-in node packages.

   Here is an example of this script: https://github.com/ilearnio/module-alias/blob/dev/index.js
   Check the weekly downloads (464 428) on NPM website https://www.npmjs.com/package/module-alias

   Wasn't typescript developed to introduce good practices into the code?

   Aliasing paths is needed especially for large codebase and helps to solve GIT conflicts after moving/refactoring the modules. Maybe it's time to change the assumptions from this comment and adjust typescript to community needs? You may see that it's needed by developers by reading related issues and checking sh***y workarounds usage statistics.

Related issues

Notice that it's not a duplication of those issues but the continuation.

• Module path maps are not resolved in emitted code #10866
• Offer option to resolve module path maps in emitted code #26722

[MartinJohns]

Duplicate of #45860, #41782, #26722 and many other. Literally the current most recent open issue is about exactly this.

[jiankafei]

@funkydev Do you have a solution?

[funkydev]

@jiankafei No. I closed my issue because it was duplication of the reported by you.

After they closed your issue as well due to the duplication, it seems that the TypeScript engineers are not going to do anything with such requests, as they didn’t invent paths aliasing to such things.

I hope they’re not living in the houses, because trees that were used to build them were created to produce oxygen, not for other purposes. 🙃

Let’s try to reopen my issue and we’ll see what happens.

---

EDIT:

Anyway, if you need aliasing for frontend apps I recommend you to research some webpack or babel solutions. I'm not into this, but I'm pretty sure that someone configured some stack for that.

Or if you need aliasing for server-side scripts check the https://www.npmjs.com/package/module-alias script. It resolves paths on runtime. I would just mark, that such scripts are unstable as they override private Node.js API and noone guarantee you that in some day it won't work as the Node team will change the codebase that shouldn't be used.

[andrewbranch]

People seem to like https://www.npmjs.com/package/@zerollup/ts-transform-paths. (I can’t recommend it personally; I just write the paths that are already going to work in my runtime/bundler, and don’t really understand why that’s too much to ask.)

[funkydev]

@andrewbranch Why did you close this issue? Your answer is another prove that the TypeScript crew should do "something" with this request.

The plugin you send isn't compatible with the native typescript library. It's for ttypescript, which is forked by a random guy probably because you didn't want to implement some functionalities.

Creating custom transformers could be a solution, but it should be supported by a native typescript library with official support. I guess that developers would be satisfied with such a solution, especially that it offers much more.

Could you share info if TypeScript supports such plugins?

Still, I don't know why did you close this issue if you didn't provide a solution on how to resolve paths using native typescript library (which this request refers to). If you want to say "do not use typescript – use everything else" just say it directly, but it's not a definition of contributing to this library, nor solves this issue.

[andrewbranch]

I closed it because it’s a duplicate. My personal solution/advice was not to write paths that don’t work at runtime—just passing along some extra information since people often seem to be unsatisfied with that solution.

[funkydev]

As I have written in the issue, it is not a duplicate but a continuation of the discussion. Moderators closed the possibility to answer under the original request created a long time ago.

My personal solution/advice was not to write paths that don’t work at runtime

I agree with you. No one should write paths that do not work at runtime. As you may see, I also described that using workarounds is not a good idea.

Having that knowledge, I reopened the discussion about paths and resolving them by typescript because I would like to do that, like many other developers. Issues exist for requesting new functionalities, and I described one above.

Seeing how you work with the community, I understand why people fork typescript and create their modifications.
Having such an approach as you have, typescript should never exist because if javascript does not offer types, you should not use them. So stupid, right?

[jiankafei]

@jiankafei No. I closed my issue because it was duplication of the reported by you.

After they closed your issue as well due to the duplication, it seems that the TypeScript engineers are not going to do anything with such requests, as they didn’t invent paths aliasing to such things.

I hope they’re not living in the houses, because trees that were used to build them were created to produce oxygen, not for other purposes. 🙃

Let’s try to reopen my issue and we’ll see what happens.

EDIT:

Anyway, if you need aliasing for frontend apps I recommend you to research some webpack or babel solutions. I'm not into this, but I'm pretty sure that someone configured some stack for that.

Or if you need aliasing for server-side scripts check the https://www.npmjs.com/package/module-alias script. It resolves paths on runtime. I would just mark, that such scripts are unstable as they override private Node.js API and noone guarantee you that in some day it won't work as the Node team will change the codebase that shouldn't be used.

My original intention is to run services on "ESM in nodejs", so the module alias scheme cannot work. In other words, TS does not support "ESM in nodejs" so far, but ESM is the trend. It is unwise for nodejs to use packaging tools, so I will not use packaging tools such as rollup. Rollup is suitable for tool library projects.

[andrewbranch]

@jiankafei #44501 contains ESM support for Node and is targeted for TypeScript 4.5

[jiankafei]

@andrewbranch After TS 4.5, in the "ESM in nodejs" project, "module alias" and other similar solutions cannot be used, so in the final analysis, the "path alias" of nodejs project is still a problem.