Improve module resolution using "paths" of "tsconfig.json" file

🔍 Search Terms

Today the "paths" property only accepts the asterisk as a wildcard character, which means it is necessary to keep redeclaring other modules when they are in subdirectories, example:

{
  "compilerOptions": {
    "paths": {
      "libs/async": ["libs/async/src"],
      "libs/async/*": ["libs/async/src/*"],
      "libs/crypto": ["libs/crypto/src"],
      "libs/crypto/*": ["libs/crypto/src/*"],
      "libs/database": ["libs/database/src"],
      "libs/database/*": ["libs/database/src/*"],
      "libs/domain": ["libs/domain/src"],
      "libs/domain/*": ["libs/domain/src/*"],
      "libs/logger": ["libs/logger/src"],
      "libs/logger/*": ["libs/logger/src/*"],
    }
  }
}

Wouldn't it be interesting to accept other characters as it happens with regex? Example:

{
  "compilerOptions": {
    "paths": {
      "libs/$1": ["libs/$1/src"],
      "libs/$1/*": ["libs/$1/src/*"],
    }
  }
}

This would make TypeScript resolution more dynamic, making it easier to set up monorepos.

✅ 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

Add more wildcards to "paths" property in tsconfig.json, like dynamic directory names ($0 for example), or create a way to use JS/TS to build and return the tsconfig object, with this I can trace the workspace folder extracting all directores needed.

📃 Motivating Example

Normally i'm use only one or 2 paths in tsconfig but I had started to work with NestJS using workspaces and each new app or library need to be added into a new element

💻 Use Cases

1. What do you want to use this for?

Any project using workspaces and having lots of sub packages

2. What shortcomings exist with current approaches?

Today is required to declare every directory manually every time when a new app or lib are created in NestJS workspace

3. What workarounds are you using in the meantime?

Today i need to make every change manually...

The request concerns the paths option in tsconfig.json, but it names no compiler source file, test, or entry point. Start by locating the existing paths handling and its module-resolution tests, then define the supported substitution syntax and compatibility behavior. Done means workspace-style paths can avoid repeated declarations and the behavior is covered by tests.