How to Ignore and Disable Type Rules Using TypeScript-ESLint

Anytime you can get TypeScript typing working with React code, it’s best to use it. However, there are times that applying TypeScript is so difficult that it is best to tactically disable it.

I’ll start with several methods of how to disable linting for a line or lines of code, because the how is factual. Then when is more opinionated, so take that with a grain of salt. The code snippets shown below can also be found in this Codesandbox.

In other news, TSLint was deprecated in late 2019 in favor of typescript-eslint. This makes a lot of sense, considering they are both linters and many people want the functionality they both provide. However, this means some of the disable syntax is a bit more verbose.

How To Ignore Rules At The File Or Line Level

  • @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.
  • @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.

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

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:


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.


Read here about how to use ESLint fix 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.

Share this post:

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.