tsconfig.json: Specify <root> in "include" and "exclude" for extends configs

Suggestion

As always, thanks again for all of your hard work on the TypeScript tooling and ecosystem! 🙌

Extends configs (configs referenced from "extends") can specify "include" and "exclude", but they are relative to the tsconfig.json file (which could be deep in node_modules) instead of the root of the directory, per the include docs:

These filenames are resolved relative to the directory containing the tsconfig.json file.

This means that the following configuration would not work as expected:

tsconfig.json

{
  "extends": "@upleveled/eslint-config-upleveled/templates/tsconfig.json"
}

node_modules/@upleveled/eslint-config-upleveled/templates/tsconfig.json

  "include": [
    "**/.eslintrc.cjs",
    "next-env.d.ts",
    "**/*.ts",
    "**/*.tsx",
    "**/*.js",
    "**/*.jsx",
    "**/*.cjs",
    "**/*.mjs"
  ],

(this would resolve relative to the node_modules deep path, which would be useless)

Removal of such broken config can also be seen in the wild here: https://github.com/tsconfig/bases/pull/41

Suggestion 1: <root> directory specifier

It would be great to get a <root> capability to add to include and exclude paths to refer to the directory with the package.json file, like Jest’s <rootDir> option:

  "include": [
    "<root>/**/*.ts"
  ]

Suggestion 2: tsconfig.ts

Another idea for implementation would be to have a code-based config (ideally tsconfig.ts, as @weswigham mentions in https://github.com/microsoft/TypeScript/issues/20110) - I’m guessing this would open up alternative ways to retrieve the root directory of the project.

Allowing TS / JS configs is a common pattern in developer tooling, and covers many use cases beyond this issue.

🔍 Search Terms

extends, extended, root directory, root folder, configs, tsconfig

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn’t be a breaking change in existing TypeScript/JavaScript code
• This wouldn’t change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn’t a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript’s Design Goals.

⭐ Suggestion

In the description above

📃 Motivating Example

In the description above

💻 Use Cases

Workaround

Specify the paths using relative paths:

  "include": [
    "../../../../**/.eslintrc.cjs",
    "../../../../next-env.d.ts",
    "../../../../**/*.ts",
    "../../../../**/*.tsx",
    "../../../../**/*.js",
    "../../../../**/*.jsx",
    "../../../../**/*.cjs",
    "../../../../**/*.mjs"
  ],

But here this encodes the directory structure of node_modules into the config as well, which is brittle.

[MartinJohns]

Related: #20110

[fatcerberus]

Using include in an extends’d config seems useless in general (or at least highly situational) because according to the docs:

It’s worth noting that files, include and exclude from the inheriting config file overwrite those from the base config file