-
Notifications
You must be signed in to change notification settings - Fork 13.1k
Description
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.jsonfile.
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.