tsconfig.json - extends property should handle more than one config paths

[RamoFX]

Suggestion - tsconfig.json - extends more than one configs

🔍 Search Terms

• tsconfig multiple extends config
• TS5024: Compiler option 'extends' requires a value of type string
• tsconfig extends
• tsconfig extends multiple
• tsconfig extends string array

✅ Viability Checklist

My suggestion meets these guidelines:

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

⭐ Suggestion

A tsconfig.json have compilerOptions, include, files and extends, I'll be describing the extends feature suggestion.

It only takes a string type which is a path to the tsconfig.json, but it would be useful to take more paths.

So extends property should be able to process one or more paths.

📃 Motivating Example

Below I attached an example code image of what this can be helpful for. The image shown tree of 7 config parts in the left side and the code example on the right of extends them together.

💻 Use Cases

What do you want to use this for?

It will give a lot of possibilities.
For example, you will be able to make one configs directory and mixing them via extends for best config and fast project configuration.

What shortcomings exist with current approaches?

Inconvenience: you need to chain them one by one, which is of course not the best practice. If you will add another one and next ot it will be another 10 files then it takes some time to make it works again.

What workarounds are you using in the meantime?

Chaining them (b extends a, c extends b, etc.).
Or you can even make some script that generates certain config from other parts.
Or maybe some package that includes all files into one.

[MartinJohns]

Related / duplicate: #29118. Used search terms: extends tsconfig in:title

[RamoFX]

Oh, you are right. Sorry for that.

[RamoFX]

The issue that you provided was opened on Dec 21, 2018 and there is no response from contributors and finally it was closed on Aug 22, 2020.

Is this feature possible? I don't think it is that hard to develop / little bit refactor.

[gurunars]

I would rather say that multiple inheritance is bad even in the context of tsconfigs.

I personally tend to generate tsconfig files before performing typescript builds. This allows me to create quite sophisticated pipelines. IMO, tsconfigs' syntax should be as blunt and featureless as possible and any extension and re-usability should be achieved at a meta level.

[MartinJohns]

Distantly related:

• tsconfig.json should support multiple configurations #37884
• Allow tsconfig.yaml in addition to tsconfig.json #40027
• Allow javascript (or typescript) config file #30400

[RamoFX]

@gurunars
I would rather say that multiple inheritance is bad even in the context of tsconfigs.

I personally tend to generate tsconfig files before performing typescript builds. This allows me to create quite sophisticated pipelines. IMO, tsconfigs' syntax should be as blunt and featureless as possible and any extension and re-usability should be achieved at a meta level.

Hi! Thanks for your advice, I'll consider it in the future.

[RyanCavanaugh]

I've reopened #29118

[mutech]

I would rather say that multiple inheritance is bad even in the context of tsconfigs.

I personally tend to generate tsconfig files before performing typescript builds. This allows me to create quite sophisticated pipelines. IMO, tsconfigs' syntax should be as blunt and featureless as possible and any extension and re-usability should be achieved at a meta level.

The same argument would hold for single inheritance. The proposition adds no features that you could not achieve with single inheritance, except for providing a better composability.

I agree that the additional complexity always adds a risk. However, the complexity of build pipelines is already suffocating and adding to that complexity is no less risky or painful. The solution for most developers who are not working on an industrial scale is typically Copy & Paste, painful comparisons of different tsconfigs, painful research in the docs to remember conflicting settings or their precise semantics.

To me, the current limitation looks like the complexity is already there, we just deny ourselves to benefit from its existence.

[mutech]

I've reopened #29118

I think it's more interesting to follow this issue, since there are conflicting opinions here.

[mutech]

Oh I meant that your ticket is more interesting, if closing was a reaction on my comment ;-)