Ability to extend compilerOptions's paths config

[xiejay97]

Suggestion

I have a tsconfig.base.json file for the monorepo, it defined paths that all project can use

{
  "compileOnSave": false,
  "compilerOptions": {
    ```
    "paths": {
      "@aegis/ui": ["libs/ui/src/index.ts"],
      "@aegis/ui/*": ["libs/ui/src/*"],
      "@aegis/shared": ["libs/shared/src/index.ts"],
      "@aegis/shared/*": ["libs/shared/src/*"]
    }
  },
  "exclude": ["node_modules", "tmp"]
}

Each project has own tsconfig.json, also defined paths that only for itself

{
  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "paths": {
      "@environment": ["src/environments/environment.ts"]
    }
  },
  "files": [],
  "include": [],
  "references": [
    {
      "path": "./tsconfig.app.json"
    },
    {
      "path": "./tsconfig.spec.json"
    },
    {
      "path": "./tsconfig.editor.json"
    }
  ]
}

Unfortunately, the paths would be overwritten.

I have to add tsconfig.base.json paths item to each project.

So, it's necessary to provide a solution for this case.

🔍 Search Terms

• compilerOptions paths extends label:Suggestion

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

[WORMSS]

There are a number of times something like "pathsAppend": [], "libsAppend": [], "referencesAppend": [], "includesAppend": []
Where we want to ADD to what ever the default/extended options are, rather than replace/override.

Libs being the most annoying even in 'standard' circumstances without extending another tsconfig, but the fact that 'adding' a single lib, REMOVES ALL the default ones added by the "target" setting. And you can't even get a definitive list of what those libs were..

[ArZargaryan]

@xiejay97 Hi. Did you find a solution or workaround?

[xiejay97]

@xiejay97 Hi. Did you find a solution or workaround?

@ArZargaryan There is no solution for me yet 😹

[harryyaprakov]

+1 This is something very important, what is a workaround for this?

[toantd90]

+1. That would be helpful if we could extend the paths configuration.

[jugglingcats]

It seems to me that since the paths are name/value, a simple merge should work, eg:

const new_paths={...basePaths, ...localPaths}

The semantics seem quite clear - use the paths in the base config (with resolution relative to that tsconfig file), and merge/overwrite any local ones (relative to the local tsconfig file).

[pmayur]

It seems to me that since the paths are name/value, a simple merge should work, eg:

const new_paths={...basePaths, ...localPaths}

@jugglingcats where should these be made?

[JorritKeijzer]

+1 Would really fix stuff in big monorepos

[kosiakMD]

+1 same issue! NX + Remix + NestJS - need local and common paths

[dben89x]

Seems this issue was addressed and closed back in 2017 on #14527 due to the suggestion being "more confusing since paths are order dependent and the paths are relative to the baseUrl, and there are two in this case". Which strikes me as an obnoxiously arrogant and dismissive take. Especially considering this can easily be resolved by simply either appending or prepending the base config, and scoping the new paths to either the current config's baseUrl or the base's baseUrl. And considering the increasing need for composite configs with monorepos, this is no longer an edge case (if you could ever argue it was one). Seems like an anti-pattern to suggest we just repeat ourselves in multiple configs.

[dannyfranca]

Folks, there has been an ongoing proposal since November 2023. Let's contribute to the discussion to help get it going: #56436