id | title |
---|---|
typed-linting |
Linting with Type Information |
Some typescript-eslint rules utilize the awesome power of TypeScript's type checking APIs to provide much deeper insights into your code. To tap into TypeScript's additional powers, there are two small changes you need to make to your config file:
/* eslint-env node */
module.exports = {
extends: [
'eslint:recommended',
// Remove this line
'plugin:@typescript-eslint/recommended',
// Add this line
'plugin:@typescript-eslint/recommended-type-checked',
],
plugins: ['@typescript-eslint'],
parser: '@typescript-eslint/parser',
// Added lines start
parserOptions: {
project: true,
tsconfigRootDir: __dirname,
},
// Added lines end
root: true,
};
:::caution
Your .eslintrc.cjs
file may start receiving a parsing error about type information.
See our TSConfig inclusion FAQ.
:::
In more detail:
plugin:@typescript-eslint/recommended-type-checked
is another recommended configuration we provide. This one contains recommended rules that additionally require type information.parserOptions.project
tells our parser how to find the TSConfig for each source file (true
indicates to find the closesttsconfig.json
for each source file)- If your project is a multi-package monorepo, see our docs on configuring a monorepo.
parserOptions.tsconfigRootDir
tells our parser the absolute path of your project's root directory (see Parser#tsconfigRootDir).
With that done, run the same lint command you ran before. You may see new rules reporting errors based on type information!
The parserOptions.project
option can be turned on with either:
true
: to always usetsconfig.json
s nearest to source filesstring | string[]
: any number of glob paths to match TSConfig files relative toparserOptions.tsconfigRootDir
, or the current working directory if that is not provided
For example, if you use a specific tsconfig.eslint.json
for linting, you'd specify:
module.exports = {
// ...
parserOptions: {
project: './tsconfig.eslint.json',
},
// ...
};
See the @typescript-eslint/parser
docs for more details.
:::note If your project is a multi-package monorepo, see our docs on configuring a monorepo. :::
You can combine ESLint's overrides config in conjunction with our disable-type-checked
config to turn off type-aware linting on specific subsets of files.
module.exports = {
extends: [
'eslint:recommended',
'plugin:@typescript-eslint/recommended',
'plugin:@typescript-eslint/recommended-type-checked',
],
plugins: ['@typescript-eslint'],
parser: '@typescript-eslint/parser',
parserOptions: {
project: true,
tsconfigRootDir: __dirname,
},
root: true,
// Added lines start
overrides: [
{
files: ['*.js'],
extends: ['plugin:@typescript-eslint/disable-type-checked'],
},
],
// Added lines end
};
:::info If you use type-aware rules from other plugins, you will need to manually disable these rules or use a premade config they provide to disable them. :::
Typed rules come with a catch.
By including parserOptions.project
in your config, you incur the performance penalty of asking TypeScript to do a build of your project before ESLint can do its linting.
For small projects this takes a negligible amount of time (a few seconds or less); for large projects, it can take longer.
Most of our users do not mind this cost as the power and safety of type-aware static analysis rules is worth the tradeoff. Additionally, most users primarily consume lint errors via IDE plugins which, through caching, do not suffer the same penalties. This means that generally they usually only run a complete lint before a push, or via their CI, where the extra time often doesn't matter.
We strongly recommend you do use type-aware linting, but the above information is included so that you can make your own, informed decision.
You're using an outdated version of @typescript-eslint/parser
.
Update to the latest version to see a more informative version of this error message, explained in our Troubleshooting and FAQs page.
If you're having problems getting this working, please have a look at our Troubleshooting and FAQs page.