Typescript: `tsconfig.extends` as array

[mutech]

Search Terms

tsconfig extends array

Suggestion

Support defining the "extends" option as array of filenames.

{ "extends": [ "a", "b", "c" ] }

would have the same result as extending c where c extends b and b extends a.

Use Cases

This would make it so much easier to compose modular configuration fragments, analogue to "presets" in babel.

Examples

Given a set of tsconfig files containing fragments:

• tsconfig/check.json (strict: ...)
• tsconfig/sourcemap.json (sourceMap: ...)
• tsconfig/declarations.json (declarations: ...)
• tsconfig/aliases.json (paths: common aliases)
• tsconfig/aliases.react.json (extends: aliases, paths: for react)
• tsconfig/aliases.preact.json (extends: aliases, paths: for preact)
• tsconfig/webpack.json (settings supporting tree shaking)
• tsconfig/babel.json (settings to let babel handle platform issues)
• tsconfig/node.json (settings to target node)
• tsconfig/browser.json (settings to target browsers)
• tsconfig/base.json (general defaults)
• ...

It would be possible to combine these fragments in a way that is much more expressive and easier to
understand than flat config files.

A/tsconfig.preact.json:

{
  "extends": ["base", "sourcemap", "declarations", "babel", "browser", "aliases.preact"],
  "compilerOptions": {
     "declarationDir": "build/A/typings",
     "outDir": "build/A-preact"
  },
  "files": [ "src/A/index.ts" ]
}

A/tsconfig.react.json:

{
  "extends": ["base", "sourcemap", "declarations", "babel", "browser", "aliases.react"],
  "compilerOptions": {
     "declarationDir": "build/A/typings",
     "outDir": "build/A-react"
  },
  "files": [ "src/A/index.ts" ]
}

tsconfig.webpack.json

{
  "extends": ["base", "webpack],
  "compilerOptions": {
  }
}

Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

[arogg]

please do this i have 4 config. 2 of them have duplicate json in them because of missing mixin ability

[mesqueeb]

Was there any feedback from the developers of tsconfig files?

[arogg]

Some more thoughts from me:

This would not be a big deal if tsconfig.js files were allowed.

Currently the only workaround is to regenerate tsconfig files via a custom tool everytime the source tsconfigs change, via file watcher.

I have the option to run typescript programmatically. But that is only for building stuff. The whole IDE experience however relies on actual real tsconfig files on the file system, and there is no way around that.

I understand the added complexity in languages like C# where multiple inheritance is not possible.
But this is not exactly inheritance like in programming languages as I see it. Are we not just talking about a (partially deep) Object.assign() here? Maybe I am just naive. I'll shut up if that is the case though :)

Of course specifying a string should still be possible for backwards compatibility and to hide "complexity".

Also lots of people also expect an array because they are used to eslint and other tools were that is possible.

I also think an array is extremely simple and intuitive to understand. It is the same as a single path, except applied multiple times. There are many options in tsconfig that are harder to understand than an extends array IMHO :)

[jordanbtucker]

Does anyone see any downsides to this, apart from the amount of work it may take to develop the feature? This seems like a no-brainer to me.

[mutech]

Looks like there is no point in opening feature tickets for this project.