Resolve TypeScript configs based on include/exclude

[brawaru]

Type: Feature Request

Hi. I have a problem with my project setup where VS Code TypeScript extension fails to find a proper tsconfig.json file.

Some context

My setup uses Rollup and rollup-plugin-dts (well, unbuild, really, which uses these) and Vitest.

My project files are written in ESM modules and using Node 16+ resolver, however any build-related files (build.config.ts by Unbuild and vitest.config.ts by Vitest), as well as tests themselves seem to be all compiled down to CJS and use legacy Node resolver. Therefore I have to have two different TS configs, not just for TS sanity, but also for TypeScript ESLint.

And here come the issues: references mechanism by TS does not work for me since all referenced project cannot disable all emits, which I'd need for build configuration files (since they're auto-compiled and don't need type declarations). Another issue is that rollup-plugin-dts does not support references, and there seem to be no plans to implement them any soon, because it's super difficult. Neither does TypeScript ESLint support references, and there haven't been much progress in two years.

So I seem to have solved compilation and ESLint issue by creating three files:

• tsconfig.base.json, which contains base compiler options;
• tsconfig.build.json, which extends tsconfig.base.json and overrides options like resolver, module, as well as includes and excludes to match only build config files and tests.
• tsconfig.project.json, which also extends tsconfig.base.json and overrides module, output directory, and includes to match only project files.

In ESLint configuration I then added

{
  // ...
  "overrides": [
    {
      "files": [
        "./build.config.ts",
        "./vitest.config.ts",
        "./build/*.ts",
        "./test/*.test.ts"
      ],
      "parserOptions": { "project": "./tsconfig.build.json" }
    }
  ]
}

Unfortunately, while this works for all tools, it does not work for Visual Studio Code, since it tries to find tsconfig.json, fails, and fall backs to use whatever is configured in VS Code itself.

Proposed solution

Perhaps VS Code TypeScript extension can match the TS config based on the include or exclude file options in separate TS configuration files.

Resolving using all tsconfig.*.json/jsconfig.*.json files won't be a good solution, since people (including me above) use partial TS configs to extend them. So there can be a setting typescript.tsconfigs which would accept an array of TS config files that should be used to resolve which opened file belongs to which TS config.

Essentially it would work like references, but won't be such a pain for other developers to support: they won't have to support anything since extending and filtering is a base functionality of TypeScript, it's users of those tools need to specify overrides, which isn't that difficult.

Would like to hear what you think of this idea or perhaps if you have a good solution/workaround to this problem.

Update: workaround

Okay, I found a workaround that works, but kind of hard to manage: to mix both references and extends. The obvious con is that you also have to make sure you override anything that tsconfig.json overrides which won't be overriden by tsconfig.base.json extend. Not having composition would be much better, so I'll leave issue open.

Perhaps you can have a massive tsconfig.base.json with all options set to their defaults, so when you extend it in composite TS config, so you're basically resetting everything to defaults and then override it, essentially using composite solely for the purpose of letting VS Code know that this TS config file exists.

• Rename tsconfig.project.json to tsconfig.json. In it add references set to [{ "path": "./tsconfig.build.json" }].
• In tsconfig.build.json's compilerOptions set composite to true.
• In your .eslintrc change parserOptions.project to tsconfig.json.

Example configs

tsconfig.base.json

{
  "compilerOptions": {
    "target": "ESNext",

    "rootDir": ".",

    "strict": true,
    "strictBindCallApply": true,

    "importsNotUsedAsValues": "error",

    "resolveJsonModule": true,
    "isolatedModules": true,
    "esModuleInterop": false,
    "allowSyntheticDefaultImports": true,

    "skipLibCheck": true
  }
}

tsconfig.json

{
  "extends": "./tsconfig.base.json",
  "compilerOptions": {
    "module": "ESNext",
    "moduleResolution": "nodenext",

    "types": [],

    "outDir": "./dist",

    "noEmit": true
  },
  "include": ["./src/**/*.ts"],
  "references": [
    {
      "path": "./tsconfig.build.json"
    }
  ]
}

tsconfig.build.json

{
  "extends": "./tsconfig.base.json",
  "compilerOptions": {
    "composite": true,

    "module": "CommonJS",

    "moduleResolution": "node",

    "esModuleInterop": true,

    "types": ["node"]
  },
  "include": [
    "./build.config.ts",
    "./vitest.config.ts",
    "./test/*.test.ts",
    "./tsconfig.build.json"
  ]
}

---

VS Code version: Code 1.75.1 (441438abd1ac652551dbe4d408dfcec8a499b8bf, 2023-02-08T21:32:34.589Z)
OS version: Windows_NT x64 10.0.19043
Modes:
Sandboxed: No

[RyanCavanaugh]

Duplicate #33094

[brawaru]

It is indeed very similar. I'll go ahead and close this then. Sorry for the duplicate, hopefully at least it gives an insight into the possible use cases :D