Repository navigation
Glob support for per pattern tsconfig configuration #21951
Description
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 #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
includeorexcludefor 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
Activity
ozyman42 commentedon Feb 8, 2019
This would be extremely useful for isomorphic TypeScript projects. For example, I currently have a project with a structure similar to
In such a scenario, it would be ideal if I got a compilation error when trying to use any dom-only globals such as
windowinsrc/node/node_client.ts,src/universal/universal_components.ts,tst/node/node_client.test.ts, ortst/universal/universal_components.test.ts. Similarly if I should also get a compilation error when trying to import a node-only module like'fs'or when trying to use a node-only global such asprocessin the filessrc/web/web_client.ts,src/universal/universal_components.ts,tst/web/web_client.test.ts, ortst/universal/universal_components.test.ts.Currently, as far as I'm aware, there is no way to accomplish this based on current tsconfig features. If this can be done with multiple tsconfig files then I am not sure how to achieve this result, because all my attempts at this have failed. However if this proposed feature was added in, then I could use a tsconfig like this in the root of the project:
[ { "compilerOptions": { "lib": ["esnext"], "types": [] } }, { "include": ["src/node/**.ts","tst/node/**.ts"], "compilerOptions": { "lib": ["esnext"], "types": ["node"] } }, { "include": ["src/web/**.ts","tst/web/**.ts"], "compilerOptions": { "lib": ["esnext","dom"], "types": [] } } ]Not only is this a much cleaner solution than 6
tsconfig.jsonfiles, but this method should should also be more straightforward for IDEs to support than multi-workspace tsconfigs which override each other.ozyman42 commentedon Feb 9, 2019
After doing some searching, I think the OP's needs could be mostly met by Project References. It still requires multiple tsconfigs, but I think you could put these all in the same folder together.
As for my problem, I figured out how to solve it using multiple tsconfigs. I won't be using Project References because I will be using webpack to compile incrementally.
lo1tuma commentedon Jun 4, 2019
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.
bolinfest commentedon Apr 14, 2020
I have an alternative proposal in #37884 that I believe would cover this, and other use cases, more generally. Instead of having a configuration defined in terms of a glob, it is given a name, and then you can set options you want on for the configuration (i.e., they can even have the same, or overlapping, globs).
This is more consistent with the general idea of "opt vs. debug" builds.
devuxer commentedon May 5, 2020
Does this issue explain why
tsc src/**/*.tsdoesn't work to recursively compile all ts files in the src directory? Always get:Note, I'm running this in PowerShell on VSCode for Windows.
karlismelderis commentedon Oct 8, 2021
I would love to see this in production.
We found some unhealthy code in production where
const [a] = datawas 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.