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

[karlhorky]

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: tsconfig/bases#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 #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: #37227

[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

[MartinJohns]

Related: #20110

[karlhorky]

Using include in an extends’d config seems useless in general (or at least highly situational)

@fatcerberus Consider projects which do not need to update the config in the extends (eg. they just want to include all files of all extensions). These projects can be very common in situations where:

1. Companies create multiple projects based on their "boilerplate", with no customizations needed for include or exclude
2. Students create multiple projects based on a programming boilerplate, with no customizations needed for include or exclude (this is our use case)

I think there are other scenarios for this type of boilerplate as well.

[karlhorky]

Another idea for implementation would be to have a code-based config (ideally tsconfig.ts, as @weswigham mentions in #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.

But I think @mhegazy is against a code-based config tsconfig.ts.

Asking whether this can be reconsidered here: #20110 (comment)

I will also add this to the issue description above.

[isqua]

Using include in an extends’d config seems useless in general (or at least highly situational)

@fatcerberus It is useful in monorepositories where you share infrastructure configurations across multiple packages.

[AxeloLabs]

I am using a monorepo, there is no way to control the output of relative file, I mean inclue, exclude, outdir, all of them are relative to the base conf. What I need is to have a base conf, that have settings that applies relatively to the current project.
I do not have inheritence working for files's outputs with tsconfig.

[shellscape]

Considering the severe limitations and perf problems that typescript-eslint has with lots of tsconfig.json files in a repo, this is sorely needed.

[karlhorky]

Thanks @sheetalkamat for implementing the ${configDir} template variable 🎉🚀

• Issue: Add template variable ${configDir} (name to be determined) for file path substitution #57485
• PR: Add template variable ${configDir} for substitution of config files directory path #58042

Looks like will be a part of TS 5.5:

• https://devblogs.microsoft.com/typescript/announcing-typescript-5-5-beta/#the-configdir-template-variable-for-configuration-files