Glob support for per pattern tsconfig configuration

It’s common to have different configurations for files in the same directory with different name patterns. The most common is file.ts and file.test.ts. We usually have different configurations for test files. For instance the global "jest" type is needed in test files but not in source files.

To separate configuration for test and source we can have two separate tsconfig.json files which "include" only test and source:

// tsconfig.json

{
  "exclude": ["*.test.ts"]
} 

Exclude glob is pending https://github.com/Microsoft/TypeScript/issues/10202

// test.tsconfig.json

{
  "include": ["*.test.ts"],
  "compilerOptions": {
    "types": ["jest"]
  }
} 

But this is not optimal for IDEs and other tsc users.

Glob based tsconfig.json

I’m proposing a glob based tsconfig.json which has different config per glob pattern:

[
        {
                // Shared config
                "compilerOptions": {}
        },
        {
                "include": ["*.test.ts"],
                "compilerOptions": {
                        "lib": ["jest"]
                }
        }
]

Changes to tsconfig.json

• It can be an array of configurations
• Each item in the array can specify include or exclude for fine grained compiler options

Resolving compiler option per file pattern

TODO

Conflicting exclude and include pattern between compiler options

TODO

this way one tsconfig.json can serve for all files with different configs per pattern

TypeScript Version: 2.7 Search Terms:

• TSConfig
• Glob
• Pattern

[lo1tuma]

Unfortunately project references don’t solve this yet, because for project references to work you need a very specific folder structure. It doesn’t work with glob patterns.

[karlismelderis]

I would love to see this in production.

We found some unhealthy code in production where const [a] = data was attempted on possibly empty arrays. We tried to enable noUncheckedIndexedAccess (https://www.typescriptlang.org/tsconfig#noUncheckedIndexedAccess)

But… Due to abnormal amount of TS errors from our test files (**/*.test.ts - like every other Jest case) enabling option would take way to much time so we couldn’t get our production code covered.