How to Ignore and Disable TypeScript Rules

This tutorial provides syntax for ignoring lint rules at the line, file, and package level. I focus on syntax for TypeScript-ESLint but will include TSLint and ESLint commands.

TSLint was deprecated in late 2019 in favor of typescript-eslint. The combined linter is a good idea because both TSLint and ESLint are linters and many people want the functionality they both provide. ESLint on its own is still a great linter for developers who are not using TypeScript.

Here is the different syntax for disabling next line rules:

• @ts-ignore – TypeScript-ESLint syntax for ignoring TypeScript rules
• eslint-disable-next-line – ESLint and TypeScript-ESLint syntax for disabling non-ts rules
• tslint:disable-next-line – deprecated TSLint syntax

This can be tricky stuff. Also, remember that these are presented as comments in the code:

In the examples below I will show details such as:

• Ignoring specific rules
• Disabling lint rules for a block of code
• Re-enabling lint rules
• Several methods for controlling file-level rule checking

Related: Test your TypeScript knowledge against these 50 difficult TypeScript questions.

I’ll start with several methods of how to disable linting, because the how is factual. Then when is more opinionated, so take that with a grain of salt.

The Resources section has a Code Sandbox link with live tutorial code that shows these rules being used.

How To Ignore Next Line With TypeScript-ESLint

There are two primary commands for ignoring the next TypeScript line:

• @ts-ignore: Ignore a single line with @ts-ignore. This actually will ignore a statement, which may be more than a single line. However, it will not ignore an entire block.

// @ts-ignore
const useStyles = makeStyles((theme) => ({
  root: {
    display: "flex",
    flexDirection: "rowssss"
  }
}));

• @ts-expect-error: Tell the compiler to expect an error (and throw an error if no error actually occured) with @ts-expect-error . An example usage from the TypeScript docs: if your unit tests are written in TypeScript, but you actually want to write a ‘breaking’ test, you can’t…unless you tell the compiler to expect an error. Simply put, this directive is more specific than @ts-ignore.

When To Use ts-expect-error Or ts-ignore

Based on the search volume I see for different keywords, most people use @ts-ignore. It’s simpler to understand and gets the job done.

The TypeScript team has these guidelines on when to use @ts-expect-error instead of @ts-ignore. The most important guideline: if you plan to fix code instead of leaving suppression errors, then use @ts-expect-error.

How To Ignore Next Line With ESLint

If you are using ESLint and you need to disable the next line, use this code:

• eslint-disable-next-line

This does not disable TypeScript rules and should not be used in files ending in .tsx. It does work in .js or .jsx files in projects with TypeScript-ESLint enabled or with standard ESLint enabled.

Here’s an example where the myName const is never used and I disable the ESLint warning.

// eslint-disable-next-line  no-unused-vars
const myName = 'Jon';

Notice the specifier of no-unused-vars. This leaves all other TypeScript and ESLint rules enabled and only disables the specific rule. You can read more about ESLint rules here.

How To Ignore Next Line With TSLint

Here is the deprecated method for ignoring or disabling a TypeScript rule in TSLint:

• tslint:disable-next-line

Only use this suppression comment if you are still using TSLint.

If you are not sure which linter you are using, check your package.json. If you see @tslint, you are using the old deprecated TypeScript linter. If you see @typescript-eslint, you are using the linter currently recommended by Palantir, the creators of TSLint.

How To Ignore File Rules With TypeScript-ESLint

• @ts-nocheck Tell the compiler to skip type checking for an entire file with @ts-nocheck . Interestingly, the opposite of this is @ts-check, which can be used to turn on type-checking for non-TypeScript files.
• ^^^Notice the syntax for the above directives did not change with the move from TSLint to typescript-eslint.
• Ignore ‘normal’ (non-TypeScript) ESLint rules: ignore multiple lines with /* eslint:disable */ and /* eslint:enable */

/* eslint-disable  @typescript-eslint/no-unused-vars */
const str: string = "asda";
const str2: string = "asda2";
/* eslint-enable  @typescript-eslint/no-unused-vars */

Here I specified the no-unused-vars command to disable. Once the offending section is over, don’t forget to re-enable the rule. It’s important to note that eslint-disable requires the use of /* */ commenting instead of // commenting syntax.

Also, eslint-disable can be used at the top of a file to turn off linting for the whole file.

Remember that ignoring and disabling using @typescript-eslint is only valid in .tsx files.

How To Ignore TypeScript-ESLint Rules At The Package Level

If you need to ignore rules across your entire app, you need to set up an eslintrc.* file.

In this file, you can specify many configs for ESlint. The “rules” config is what we are looking for. Here’s an example of disabling no-unused-vars for the whole app.

rules: {
    
    "@typescript-eslint/no-unused-vars": "off",
}

At the time of updating this article (June 2021), Code Sandbox does not yet support eslintrc.* files (Check this thread for updates).

If you are using ESlint, but not typescript-eslint, you may be aware that you can add rules in package.json under eslintConfig.

"eslintConfig": {
    "rules": {
      "no-unused-vars": "off"
    }
  },

However, typescript-eslint does not look at the package.json for rules and currently requires an actual eslintrc.* file.

When To Ignore TypeScript-ESLint Rules

Some teams may implement ban-ts-comment in the eslintrc file, which blocks the following:

@ts-expect-error
@ts-ignore
@ts-nocheck
@ts-check

This means the team finds it unacceptable to ever ignore a rule (and block team members from doing so).

These are a few suggestions, and they are not hard-and-fast rules.

• When using a third-party library that is poorly typed. It’s not your job to fix their typing or dig into their code.
• When TypeScript’s type widening causes reasonable code to be flagged. Is it better to change the code to be less clear, or to simply ignore the line? See this example in the Material-UI docs where flexDirection: 'column' is flagged. TypeScript widens ‘column’ to string, which is incompatible with flexDirection. The MUI docs describe how to fix this, but should we really please the compiler here, or should we simply move on?
• When data from BE is so complex that it would take multiple hours to figure out TypeScript compatibility. Consider this: you already have a contract with BE. Perhaps it is simply best to cast the type and do actual value-adding work.

If you want a great rules list to start from, take a look at the AirBnB rules package and style guide.

Resources

Here’s how to use ESLint fix in your project.

Here’s how to configure the @typescript-eslint/ban-types rule in your project.

Here’s how and when to specify global variables in your .eslintrc file.

Some of the most important ESLint rules are found in the jsx-a11y plugin, which enforces web accessibility standards. Read about the top five rules here, and here’s how to fix jsx-a11y/interactive-supports-focus errors.