references are not inherited in tsconfig.json

[borekb]

TypeScript Version: 3.1.0-dev.20180914

Search Terms: tsconfig.json extends references inheritance

It seems that the references key is not inherited via the extends mechanism, which surprised me because the handbook doesn't mention anything special about it.

Demo:

tsconfig.base.json:

{
  "references": [
    { "path": "./some/other/project" }
  ],
  "compilerOptions": {
    "declaration": true,
    "composite": true
  }
}

tsconfig.doesnt-work.json:

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

Building tsconfig.doesnt-work.json doesn't build the reference:

$ tsc -b -f -d tsconfig.doesnt-work.json
[11:12:13] A non-dry build would build project 'C:/demo/tsconfig.doesnt-work.json'

tsconfig.works-but-duplicates-references.json:

{
  "extends": "./tsconfig.base.json",
  "references": [
    { "path": "./some/other/project" }
  ],
}

This is a correct build but I had to duplicate the references key:

$ tsc -b -f -d tsconfig.works-but-duplicates-references.json
[11:12:13] A non-dry build would build project 'C:/demo/tsconfig.works-but-duplicates-references.json'
[11:12:13] A non-dry build would build project 'C:/demo/some/other/project/tsconfig.json'

[RyanCavanaugh]

This is the intended behavior but we need to document it

[NoelAbrahams]

@RyanCavanaugh, what was the reasoning behind disallowing inheritance of the "reference" setting? In the old <reference> tag set-up all references of the "base" project were automatically inherited by the "client" project.

IMO that seemed to be the outcome of least surprise.

[jonaskello]

I tried to use inheritance of references section to setup a second tsconfig.json for production builds (without sourcemaps etc.). Since there is no inheritance I need to duplicate the refrences section. Perahps I'm not doing the right solution for this scenario? How would you handle a separate production build with project references?

[ggradnig]

@RyanCavanaugh, still curious about the reasoning behind this design decision.

I have a use case where I need to switch the module system from es6 to commonjs for my karma-typescript tests. This is easily done by extending the original tsconfig, changing this option and referencing the extended tsconfig in the karma config. But by doing so, all the project references are lost.

While there may be reasons for not wanting to extend this attribute, I think there are also legitimate reasons for doing so. Copying the references is error-prone, people forget about it. Maybe you can find a way to allow this in a future version. Thanks :)

[RyanCavanaugh]

For some hierarchy

A
⬆
B
⬆
C

B could be, for example:

• An opaque library that doesn't intend to expose its reliance on A to its consumer C and leaks no types from A
• A helper library that adds additional A-related functionality that C might want to use

If references are inherited, then the first scenario is impossible to do.

If they're not inherited, then you can pick which you mean from C's perspective.

[MeirionHughes]

Got caught by this. In my setup I have: tsconfig.json and tsconfig.build.json per package. the first is for testing (via mocha + ts-node) and the second is derived from the first, but altered for the distribution build. Without inheritance of references I now have to duplicate them in both.

I don't understand why you can't, in an inherited tsconfig, just set the 'references' to an empty array in order to override the inheritance (completely).

perhaps introducing a keyword to signal intent might be the way to go?

i.e.

"references": [   
    "inherit",
    {
      "path": "../some-extra-dep/tsconfig.json"
    }
]

[Adamfsk]

@RyanCavanaugh Rather than having an extra tag in references, why not optionally allow references to be placed into a separate json file and then be refer to it in the config?

That way cases where people specifically want to list their references in a single location and share those references between two or more tsconfig.json files, they can do so without impacting those that might be affected the proper functioning of your first scenario above?

[zbigg]

@RyanCavanaugh Thanks for explanation, but I'm not sure if expected behavior and explanation provided aligns with common understanding of what "extends" mean in scope of configuration.

The example you've provided make perfect sense if A, B, C would be libraries and edges are use relations, which should be private and that's how it works in proper dependency resolution systems.

Whereas, when it comes to configuration - at least pople in this thread - inheritance means "just" take all the props from parent config, so basic "public" inheritance like we experience with Typescript extends and/or _.merge.

So, summarizing design you're referring IMHO conflicts with common understanding of inheritance in configuration systems.

Is there chance to have workaround? (given that - assuming from your comment - current behavior is already set in stone).

[Bessonov]

I support the opinion, that current inheritance model isn't optimal.

Because tsconfig.json is a plain json file (very pity!), there is no sophisticated way to workaround it. Just for simply cases for monorepos I would like to promote my alpha set-project-references helper. It doesn't help with inheritance, but makes life with project references easier.

[dfee]

^^ Documented this as it bit me hard tonight.

[laszlopandy]

In the handbook it says:

files, include and exclude from the inheriting config file overwrite those from the base config file.

Following the principle of lease surprise, references should also inherit and overwrite those from the base config file.

Regarding what Ryan said:

An opaque library that doesn't intend to expose its reliance on A to its consumer C and leaks no types from A
...
If references are inherited, then the first scenario is impossible to do.

Is it still impossible if we allow references to override even if it's empty?

{
    "extends": "./tsconfig-other.json",
    "references": [],
}

[silasdavis]

Surprised++

The hierarchy/hiding argument seems a bit weak to me. Let's make those edge cases not use inheritance and just copypasta rather than changing what inheritance means structurally.

I am also trying to create a production build and avoid to compiling tests files that depend on test packages. If I exclude test files from my normal tsconfig that breaks other things (like IDEs) so I am attempting to write a production.tsconfig.json that has the necessary exclusions but otherwise does want the primary does.

[lukebelbina]

I'll jump in this and bump this issue. I have a tsconfig.build.json to exclude test files from builds and expected references to inherit as this isn't clearly documented.

It isn't particularly optimal to duplicate the references in tsconfig.json and tsconfig.build.json but seems like that's the only working solution currently?

[alexpusch]

this is my unfortunate workaround for this issue:
A script that copies tsconfig, adds the tests folder into the exclude list and runs tsc on this new config file

It would be really nice to get a real solution for this.

const path = require("path");
const fs = require("fs");
const spawn = require("child_process").spawn;

const tsConfigPath = path.join(process.cwd(), "tsconfig.json");
const tsConfig = require(tsConfigPath);
tsConfig.exclude = tsConfig.exclude ?? [];
tsConfig.exclude.push("src/test");

const prodTsPath = "tsconfig.prod.json";

fs.writeFileSync(prodTsPath, JSON.stringify(tsConfig, null, 2));

const tscProcess = spawn("tsc", ["--build", prodTsPath], { cwd: process.cwd() });
tscProcess.stdout.pipe(process.stdout);
tscProcess.stderr.pipe(process.stderr);

tscProcess.on("close", (code) => {
  fs.rmSync(prodTsPath);

  setImmediate(process.exit(code));
});

[deanhiller]

seems to be best monorepo setup I have found to date for typescript. This would be amazing if fixed. Reference blog that refers to this bug -> https://blog.ah.technology/a-guide-through-the-wild-wild-west-of-setting-up-a-mono-repo-with-typescript-lerna-and-yarn-ed6a1e5467a

[DesignByOnyx]

This one just bit me hard. And since it has been this way for years there's no way to roll it back in. This is a real bummer because separate build/test/lint configs are more necessary than not, and generally they all extend a base config.

Maybe the "extends" property can accept an object with an includeReferences property which defaults to false to match the current behavior. This could also work with the new array format for extends:

{
  "extends": {
    "path": "../path/to/project",
    "includeReferences": true
  }
}

[githorse]

I have dozens of packages in my monorepo, and I want to exclude test files from my production builds. So I need dozens of tsconfig.build.json files alongside my tsconfig.json files to specify the excluded tests -- but now I have to specify those dozens of lists of project references twice. This design pretty well guarantees I will trip myself up over and over by forgetting to add something in the second file.

Would definitely like to understand better why the references can't be inherited ...

[jtwebman]

I think this is dumb. Why have references at all! Instead just look at the node_modules folders and go up the tree like node does. Then all these workspaces would just work without having to manually add references or even worse add some huge library like Nx to manage it all. It is like they want to make it as complex as possible.

[cantecim]

Oh god... This should be implemented.. Any update on this is it considered or not?