TypeScript: The `compilerOptions.outDir` config is incorrectly resolved when in a shareable config

Rather than a breaking fix, couldn’t one just handle placeholder variables, such as $PROJECT_DIR or $ROOT_DIR? So the outDir in my common config file could be "$PROJECT_DIR/lib"?

Path-based compiler options (outDir, outFile, rootDir, include, files) are resolved from the config file they’re found in - we thought this’d be more consistent when combining config files, especially when you have multiple configs within the same project, as paths always get resolved relative to the file they were written in (so you can safely write references to any path you want in a config file without worrying about if that config gets extend’d later on - its paths will continue to work).

It would be horribly breaking to change this behavior now~

As per @MartinDoyleUK 's suggestion - which is similar to what Jest has done with <rootDir>, please add a $ROOT_DIR option to support this common use case.

Just want to chime in, I’m really surprised these paths are resolving relatively. This really makes config extensions much less useful.

I really just want to set my rootDir and outDir across all of my packages uniformly by extending a singular base configuration - there’s no way to do that right now without defining rootDir and outDir in every single one of my packages.

Took me a hot minute to find my build files inside node_modules/@myorg/shared-tsconfigs/dist… 😭

But this makes “extends” pretty useless. Without outDir you cannot use project references with extends. A The use case for extends is that I specify baseline options for the compiler but paths and references should be based on project settings. It should be possible overwrite paths or even individual options.

@myscope/tsc-config/tsconfig.base.json

{
  "compilerOptions": {
    "moduleResolution": "node",
    "target": "ES2018",
    "newLine": "lf",
    "jsx": "react",
    "strict": true,
    "allowSyntheticDefaultImports": false
}

@myscope/my-project/tsconfig.json

{
  "extends": "@myscope/tsc-config/tsconfig.base.json",
  "compilerOptions": {
    "moduleResolution": "node",
    "target": "ES2018",
    "newLine": "lf",
    "jsx": "react",
     "outDir": "lib",
    "strict": true,
    "allowSyntheticDefaultImports": true
}

Resolved config:

{
  "compilerOptions": {
    "moduleResolution": "node",
    "target": "ES2018",
    "newLine": "lf",
    "jsx": "react",
     "outDir": "@myscope/my-project/lib",
    "strict": true,
    "allowSyntheticDefaultImports": true
}

This should be a non-breaking change.

4 years and we still can’t get one of the non-breaking solutions merged?

@weswigham any news on this?

I found @MartinDoyleUK’s idea to intro $PROJECT_DIR or $ROOT_DIR vars quite smart and they aren’t a breaking change.

I think this is very confusing, I read the docs about extends and when I read:

All relative paths found in the configuration file will be resolved relative to the configuration file they originated in.

I took this at it’s word that if I used a relative path such as

{
  ...
  outDir: './src',
  ...
}

in the base configuration path would be resolved relative to the base configuration’s path. The implication here is that non-relative paths are not relative to where they appear but rather the project wherever tsc is run, so I expect:

{
  ...
  outDir: 'src',
  ...
}

to be relevant to the project.

It seems however that src and ./src are both identical wrt extends which seems like a very unintuitive decision.

This is honestly crazy. about five years later and we still don’t have anything.

even just an extra config property we could put in the base/shared config like outDirBaseUrlOverride or allowExtendOutDir would be a good simple fix which i cant imagine being a breaking change as its something that needs to be manually enabled

We’re discussing options about this at #56436

I ran into this while making pnpm use a shared config.

It’s such a surprise that extends resolves path relatively to the source config rather than the inhering config.

Consistency? YES definitely. Use case? NO Don’t think so.

As a workaround, here is my hack:

1. link the source tsconfig.json to the same directory of target project e.g.

$ ln -s node_modules/<tsconfig_config_pkg>/tsconfig.json tsconfig.base.json

1. then make a tsconfig.json which extendstsconfig.base.json e.g.

{ "extends": "./tsconfig.base.json"}

Would be great if suggestion such as #30163 can be accepted!!!

Hello from 2024, this is still an issue.

Wow, great to know a solution has been implemented and merged!

https://github.com/microsoft/TypeScript/pull/58042

As far as I understand it, soon we should be able to write a base config such as:

// @fileName: tsconfig.base.json
{
  "compilerOptions": {
    "rootDir": "${configDir}/src",
    "outDir": "${configDir}/lib",
    "tsBuildInfoFile": "${configDir}/lib/.tsbuildinfo",
  } 
}

Hello from 2024, this is still an issue.

Is typescript still maintained?

I just was making a new project in TS (pretty much the first time I’m doing a monorepo TS project from the scratch) and I also faced this issue. I was expecting paths to be resolved from the “final” tsconfig.json file.

None of workarounds menitoned during the discussion works. I also have a feeling that adding root directory variable would be a viable solution to this - though discovery of it wouldn’t be perfect.

The only solution for me is to use:

{
    "extends": "../tsconfig-package.json",
    "compilerOptions": {
        "outDir": "./dist", // Needed due to https://github.com/microsoft/TypeScript/issues/29172.
    }
}

Which is not ideal but still makes few lines to be reused.