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

[sindresorhus]

TypeScript Version: 3.3.0-dev.20181222

Search Terms: outDir, output directory, outDir extends

Expected behavior:

TypeScript 3.2 got support for configuration inheritance via node_modules packages. I have created a package with a shareable config. In this shareable config, I have defined the outDir option: https://github.com/sindresorhus/tsconfig/blob/50b0ba611480ed45b97a59b910f5bb5e8cbc25ef/tsconfig.json#L2-L3 as I always use the same outDir and don't want to have to specify it in each project.

I expected the outDir path to be resolved against the project root, even when it's defined in an extended config.

Actual behavior:

It turns out the outDir relative path is actually resolved against the shareable config path instead of the project's root (tsconfig.json) path. So when I have a project foo, and compile TypeScript, the output ends up in foo/@sindresorhus/tsconfig/dist instead of foo/dist.

You can reproduce it by cloning https://github.com/sindresorhus/ow/tree/8ae048c4931dfd51b496cefb40b24c78d3722be6, then removing this line https://github.com/sindresorhus/ow/blob/8ae048c4931dfd51b496cefb40b24c78d3722be6/tsconfig.json#L4 (which is a workaround to the problem), and then run $ npm test. The compiled TS code will end up in node_modules/@sindresorhus/tsconfig/dist instead of dist.

[weswigham]

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~

[chyzwar]

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.

[mmmeff]

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... 😭

[mmmeff]

You're correct that this is a breaking change though. Everyone is setting their paths in shared configs with ../../ prefixing them. You can imagine what would happen if you made these paths start resolving from their downstream consumer's roots.

[ravenscar]

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.

[mmmeff]

Since changing this behavior would be a breaking change and is impossible to make backwards compatible, could we maybe create new keys that resolve relatively?

I vote srcDir (similar to nuxt) and distDir. From there deprecation notices can be added to users still using rootDir and outDir.

I'm opposed to the idea of making them something explicit like relativeOutDir and relativeRootDir because I don't think the current behavior should be the default behavior - it's very confusing to anyone attempting to use extended configurations

[NoelAbrahams]

The current implementation is rather unfortunate as it results in surprising behaviour. In addition to outDir, outFile, rootDir, include, exclude, files we now also have tsBuildInfoFile.

Incidentally, in the MSBuild config inheritance implementation (Directory.build.props), the setting for <OutputPath>mypath</OutputPath> is absolute. Hence can be conveniently defined at the solution level.

There is a proposal for a non-breaking implementation in #30163

[kirillgroshkov]

I agree, got confused about it as well. Any plans to change this behaviour to support relative paths in shareable configs?

[MartinDoyleUK]

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"?

[alvis]

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!!!

[ExE-Boss]

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

[Bessonov]

@weswigham what's about this comment from @MartinDoyleUK ?

Would love to see this solution.

[clehene]

Not sure if related or different bug / feature, but I have (v 3.6.3):

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

If I use the path in imports:

import logger from 'common/logger';

generated files will look like:

NOTE there's a copy of logger in server src

server/dist
├── common
│   └── src
│       ├── logger.js
│       └── logger.js.map
└── server
    └── src
        ├── csp.js
        ├── csp.js.map
        ├── index.js
        ├── index.js.map
        ├── logger.js
        ├── logger.js.map

without the import using the path config (but keeping the path config)

import logger from './logger';

server/dist
├── csp.js
├── csp.js.map
├── index.js
├── index.js.map
├── logger.js
├── logger.js.map

Full tsconfig

{
  "compilerOptions": {
    "module": "commonjs",
    "declaration": false,
    "noImplicitAny": false,
    "removeComments": true,
    "noLib": false,
    "allowSyntheticDefaultImports": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "target": "es6",
    "sourceMap": true,
    "allowJs": true,
    "outDir": "./dist",
    "skipLibCheck": true,
    "baseUrl":"./src",
    "paths": {
      "common/*": ["../../common/src/*"]
    }
  },
  "exclude": [
    "node_modules"
  ],
  "include": [
    "src/**/*"
  ]
}

build command

tsc -p tsconfig.json