Repository: TypeScript
Issue: Allow overrides in tsconfig
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

- tsconfig
- overrides
- eslint
- glob

## Suggestion

<!-- A summary of what you'd like to see added or changed -->

It would be nice if `tsconfig.json` files would allow an `overrides` section which works in the same way [as ESLint](https://eslint.org/docs/user-guide/configuring#configuration-based-on-glob-patterns). Here I have just one config file in my root for all kind of files and use cases. TypeScript currently needs multiple `tsconfig.json` files.

## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

As far as I know editors like VS Code look for the nearest `tsconfig.json` for proper TypeScript support. This make it hard to properly type files which are used for different environments (e.g. source code vs tests vs storybook examples and so on) in the same directory, which seems to be a common convention nowadays (e.g. `src/file.ts`, `src/file.test.ts`, `src/file.stories.ts`).

Most people seem to ignore this fact which makes test globals like `describe` available in source code files.

I once [tweeted](https://twitter.com/PipoPeperoni/status/1166228487268683777
) about this with a small example:

## Examples

<!-- Show how this would be used and what the behavior would be -->

```json
{
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "module": "esnext",
    "moduleResolution": "node",
    "noEmit": true,
    "strict": true,
    "skipLibCheck": true,
    "target": "es2017",
    "types": []
  },
  "overrides": [
    {
      "include": ["src/**/*"],
      "exclude": ["src/**/*.test.ts"],
      "compilerOptions": {
        "jsx": "react",
        "types": ["webpack-env"],
        "plugins": [
          {
            "name": "typescript-styled-plugin"
          }
        ]
      }
    },
    {
      "include": ["src/**/*.test.ts"],
      "compilerOptions": {
        "types": ["jest", "node"]
      }
    }
  ]
}
```

## 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](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).