Skip to main content

prefer-ts-expect-error

Enforce using @ts-expect-error over @ts-ignore.

🔧

Some problems reported by this rule are automatically fixable by the --fix ESLint command line option.

Deprecated

This rule has been deprecated in favor of @typescript-eslint/ban-ts-comment. This rule (@typescript-eslint/prefer-ts-expect-error) will be removed in a future major version of typescript-eslint.

When it was first created, @typescript-eslint/ban-ts-comment rule was only responsible for suggesting to remove @ts-ignore directive. It was later updated to suggest replacing @ts-ignore with @ts-expect-error directive, so that it replaces @typescript-eslint/prefer-ts-expect-error entirely.

TypeScript allows you to suppress all errors on a line by placing a comment starting with @ts-ignore or @ts-expect-error immediately before the erroring line. The two directives work the same, except @ts-expect-error causes a type error if placed before a line that's not erroring in the first place.

This means it's easy for @ts-ignores to be forgotten about, and remain in code even after the error they were suppressing is fixed. This is dangerous, as if a new error arises on that line it'll be suppressed by the forgotten about @ts-ignore, and so be missed.

eslint.config.mjs
export default tseslint.config({
  rules: {
    "@typescript-eslint/prefer-ts-expect-error": "error"
  }
});

Try this rule in the playground ↗

Examples​

This rule reports any usage of @ts-ignore, including a fixer to replace with @ts-expect-error.

// @ts-ignore
const str: string = 1;

/**
 * Explaining comment
 *
 * @ts-ignore */
const multiLine: number = 'value';

/** @ts-ignore */
const block: string = 1;

const isOptionEnabled = (key: string): boolean => {
  // @ts-ignore: if key isn't in globalOptions it'll be undefined which is false
  return !!globalOptions[key];
};
Open in Playground

Options​

This rule is not configurable.

When Not To Use It​

If you are compiling against multiple versions of TypeScript and using @ts-ignore to ignore version-specific type errors, this rule might get in your way. You might consider using ESLint disable comments for those specific situations instead of completely disabling this rule.

Further Reading​

Resources​