Glob support for per pattern tsconfig configuration

[mohsen1]

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 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

[ozyman42]

This would be extremely useful for isomorphic TypeScript projects. For example, I currently have a project with a structure similar to

src/
|____web/
|    |____web_client.ts
|____node/
|    |____node_client.ts
|____universal/
|    |____universal_components.ts
tst/
|____web/
|    |____web_client.test.ts
|____node/
|    |____node_client.test.ts
|____universal/
     |____universal_components.test.ts

In such a scenario, it would be ideal if I got a compilation error when trying to use any dom-only globals such as window in src/node/node_client.ts, src/universal/universal_components.ts, tst/node/node_client.test.ts, or tst/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 as process in the files src/web/web_client.ts, src/universal/universal_components.ts, tst/web/web_client.test.ts, or tst/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.json files, but this method should should also be more straightforward for IDEs to support than multi-workspace tsconfigs which override each other.

[ozyman42]

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]

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]

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]

Does this issue explain why tsc src/**/*.ts doesn't work to recursively compile all ts files in the src directory? Always get:

error TS6053: File 'src/netlify/functions/**/*.ts' not found.

Note, I'm running this in PowerShell on VSCode for Windows.

[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.