ESLint Plugin TypeScript

Getting Started

You can find our Getting Started docs here You can find our FAQ / Troubleshooting docs here

These docs walk you through setting up ESLint, this plugin, and our parser. If you know what you're doing and just want to quick start, read on...

Quick-start

Installation

Make sure you have TypeScript and @typescript-eslint/parser installed, then install the plugin:

yarn add -D @typescript-eslint/eslint-plugin

It is important that you use the same version number for @typescript-eslint/parser and @typescript-eslint/eslint-plugin.

Note: If you installed ESLint globally (using the -g flag) then you must also install @typescript-eslint/eslint-plugin globally.

Usage

Add @typescript-eslint/parser to the parser field and @typescript-eslint to the plugins section of your .eslintrc configuration file, then configure the rules you want to use under the rules section.

{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"],
  "rules": {
    "@typescript-eslint/rule-name": "error"
  }
}

You can also enable all the recommended rules for our plugin. Add plugin:@typescript-eslint/recommended in extends:

{
  "extends": ["plugin:@typescript-eslint/recommended"]
}

Note: Make sure to use eslint --ext .js,.ts since by default eslint will only search for .js files.

Recommended Configs

You can also use eslint:recommended (the set of rules which are recommended for all projects by the ESLint Team) with this plugin. As noted in the root README, not all ESLint core rules are compatible with TypeScript, so you need to add both eslint:recommended and plugin:@typescript-eslint/eslint-recommended (which will adjust the one from ESLint appropriately for TypeScript) to your config:

{
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/eslint-recommended",
    "plugin:@typescript-eslint/recommended"
  ]
}

As of version 2 of this plugin, by design, none of the rules in the main recommended config require type-checking in order to run. This means that they are more lightweight and faster to run.

Some highly valuable rules simply require type-checking in order to be implemented correctly, however, so we provide an additional config you can extend from called recommended-requiring-type-checking. You would apply this in addition to the recommended configs previously mentioned, e.g.:

{
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/eslint-recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:@typescript-eslint/recommended-requiring-type-checking"
  ]
}

Pro Tip: For larger codebases you may want to consider splitting our linting into two separate stages: 1. fast feedback rules which operate purely based on syntax (no type-checking), 2. rules which are based on semantics (type-checking).

Supported Rules

Key: :heavy_check_mark: = recommended, :wrench: = fixable, :thought_balloon: = requires type information

Name	Description	:heavy_check_mark:	:wrench:	:thought_balloon:
`@typescript-eslint/adjacent-overload-signatures`	Require that member overloads be consecutive	:heavy_check_mark:
`@typescript-eslint/array-type`	Requires using either `T[]` or `Array<T>` for arrays		:wrench:
`@typescript-eslint/await-thenable`	Disallows awaiting a value that is not a Thenable	:heavy_check_mark:		:thought_balloon:
`@typescript-eslint/ban-ts-comment`	Bans `// @ts-<directive>` comments from being used
`@typescript-eslint/ban-types`	Bans specific types from being used	:heavy_check_mark:	:wrench:
`@typescript-eslint/consistent-type-assertions`	Enforces consistent usage of type assertions	:heavy_check_mark:
`@typescript-eslint/consistent-type-definitions`	Consistent with type definition either `interface` or `type`		:wrench:
`@typescript-eslint/explicit-function-return-type`	Require explicit return types on functions and class methods	:heavy_check_mark:
`@typescript-eslint/explicit-member-accessibility`	Require explicit accessibility modifiers on class properties and methods
`@typescript-eslint/explicit-module-boundary-types`	Require explicit return and argument types on exported functions' and classes' public class methods
`@typescript-eslint/member-delimiter-style`	Require a specific member delimiter style for interfaces and type literals	:heavy_check_mark:	:wrench:
`@typescript-eslint/member-ordering`	Require a consistent member declaration order
`@typescript-eslint/naming-convention`	Enforces naming conventions for everything across a codebase			:thought_balloon:
`@typescript-eslint/no-dynamic-delete`	Disallow the delete operator with computed key expressions		:wrench:
`@typescript-eslint/no-empty-interface`	Disallow the declaration of empty interfaces	:heavy_check_mark:	:wrench:
`@typescript-eslint/no-explicit-any`	Disallow usage of the `any` type	:heavy_check_mark:	:wrench:
`@typescript-eslint/no-extra-non-null-assertion`	Disallow extra non-null assertion
`@typescript-eslint/no-extraneous-class`	Forbids the use of classes as namespaces
`@typescript-eslint/no-floating-promises`	Requires Promise-like values to be handled appropriately			:thought_balloon:
`@typescript-eslint/no-for-in-array`	Disallow iterating over an array with a for-in loop	:heavy_check_mark:		:thought_balloon:
`@typescript-eslint/no-implied-eval`	Disallow the use of `eval()`-like methods			:thought_balloon:
`@typescript-eslint/no-inferrable-types`	Disallows explicit type declarations for variables or parameters initialized to a number, string, or boolean	:heavy_check_mark:	:wrench:
`@typescript-eslint/no-misused-new`	Enforce valid definition of `new` and `constructor`	:heavy_check_mark:
`@typescript-eslint/no-misused-promises`	Avoid using promises in places not designed to handle them	:heavy_check_mark:		:thought_balloon:
`@typescript-eslint/no-namespace`	Disallow the use of custom TypeScript modules and namespaces	:heavy_check_mark:
`@typescript-eslint/no-non-null-asserted-optional-chain`	Disallows using a non-null assertion after an optional chain expression
`@typescript-eslint/no-non-null-assertion`	Disallows non-null assertions using the `!` postfix operator	:heavy_check_mark:
`@typescript-eslint/no-parameter-properties`	Disallow the use of parameter properties in class constructors
`@typescript-eslint/no-require-imports`	Disallows invocation of `require()`
`@typescript-eslint/no-this-alias`	Disallow aliasing `this`	:heavy_check_mark:
`@typescript-eslint/no-throw-literal`	Disallow throwing literals as exceptions			:thought_balloon:
`@typescript-eslint/no-type-alias`	Disallow the use of type aliases
`@typescript-eslint/no-unnecessary-condition`	Prevents conditionals where the type is always truthy or always falsy		:wrench:	:thought_balloon:
`@typescript-eslint/no-unnecessary-qualifier`	Warns when a namespace qualifier is unnecessary		:wrench:	:thought_balloon:
`@typescript-eslint/no-unnecessary-type-arguments`	Enforces that type arguments will not be used if not required		:wrench:	:thought_balloon:
`@typescript-eslint/no-unnecessary-type-assertion`	Warns if a type assertion does not change the type of an expression	:heavy_check_mark:	:wrench:	:thought_balloon:
`@typescript-eslint/no-unused-vars-experimental`	Disallow unused variables and arguments			:thought_balloon:
`@typescript-eslint/no-var-requires`	Disallows the use of require statements except in import statements	:heavy_check_mark:
`@typescript-eslint/prefer-as-const`	Prefer usage of `as const` over literal type		:wrench:
`@typescript-eslint/prefer-for-of`	Prefer a ‘for-of’ loop over a standard ‘for’ loop if the index is only used to access the array being iterated
`@typescript-eslint/prefer-function-type`	Use function types instead of interfaces with call signatures		:wrench:
`@typescript-eslint/prefer-includes`	Enforce `includes` method over `indexOf` method	:heavy_check_mark:	:wrench:	:thought_balloon:
`@typescript-eslint/prefer-namespace-keyword`	Require the use of the `namespace` keyword instead of the `module` keyword to declare custom TypeScript modules	:heavy_check_mark:	:wrench:
`@typescript-eslint/prefer-nullish-coalescing`	Enforce the usage of the nullish coalescing operator instead of logical chaining		:wrench:	:thought_balloon:
`@typescript-eslint/prefer-optional-chain`	Prefer using concise optional chain expressions instead of chained logical ands		:wrench:
`@typescript-eslint/prefer-readonly`	Requires that private members are marked as `readonly` if they're never modified outside of the constructor		:wrench:	:thought_balloon:
`@typescript-eslint/prefer-regexp-exec`	Enforce that `RegExp#exec` is used instead of `String#match` if no global flag is provided	:heavy_check_mark:		:thought_balloon:
`@typescript-eslint/prefer-string-starts-ends-with`	Enforce the use of `String#startsWith` and `String#endsWith` instead of other equivalent methods of checking substrings	:heavy_check_mark:	:wrench:	:thought_balloon:
`@typescript-eslint/promise-function-async`	Requires any function or method that returns a Promise to be marked async			:thought_balloon:
`@typescript-eslint/require-array-sort-compare`	Requires `Array#sort` calls to always provide a `compareFunction`			:thought_balloon:
`@typescript-eslint/restrict-plus-operands`	When adding two variables, operands must both be of type number or of type string			:thought_balloon:
`@typescript-eslint/restrict-template-expressions`	Enforce template literal expressions to be of string type			:thought_balloon:
`@typescript-eslint/strict-boolean-expressions`	Restricts the types allowed in boolean expressions			:thought_balloon:
`@typescript-eslint/triple-slash-reference`	Sets preference level for triple slash directives versus ES6-style import declarations	:heavy_check_mark:
`@typescript-eslint/type-annotation-spacing`	Require consistent spacing around type annotations	:heavy_check_mark:	:wrench:
`@typescript-eslint/typedef`	Requires type annotations to exist
`@typescript-eslint/unbound-method`	Enforces unbound methods are called with their expected scope	:heavy_check_mark:		:thought_balloon:
`@typescript-eslint/unified-signatures`	Warns for any two overloads that could be unified into one by using a union or an optional/rest parameter

Extension Rules

In some cases, ESLint provides a rule itself, but it doesn't support TypeScript syntax; either it crashes, or it ignores the syntax, or it falsely reports against it. In these cases, we create what we call an extension rule; a rule within our plugin that has the same functionality, but also supports TypeScript.