JS with Types Start

TypeScript error

TS2578: A // @ts-expect-error with nothing to expect

  • Error TS2578
  • Tested with TypeScript 5.9

error TS2578: Unused '@ts-expect-error' directive. is reported on a // @ts-expect-error comment when the line after it has no error. Unlike // @ts-ignore, which hides whatever is there, @ts-expect-error insists that an error exists, so it tells you when the reason for it is gone.

In a JavaScript project this usually appears after a fix or an upgrade: the call that used to fail now type-checks, and the comment that silenced it is stale.

At a glance

CodeTS2578
MessageUnused '@ts-expect-error' directive.
TypeScript's categoryerror
Listed underClasses, JSX and unused code
Turned on by No option: every checked file reports it
In .js files Reported when the file is checked: checkJs in jsconfig.json, or // @ts-check at the top of the file

The message is TypeScript's own text from its diagnostic messages file (Apache-2.0).

What it looks like

price.js Error confirmed 5.9.3 TypeScript 5.9.3, run 21 October 2026: price.js(7,1): error TS2578: Unused '@ts-expect-error' directive. 6.0.3 TypeScript 6.0.3, run 21 October 2026: the same as 5.9.3. price.js(7,1): error TS2578: Unused '@ts-expect-error' directive. 7.0.2 TypeScript 7.0.2, run 21 October 2026: the same as 5.9.3. price.js(7,1): error TS2578: Unused '@ts-expect-error' directive. checked 21 October 2026 
/** @param {number} cents */
export function formatPrice(cents) {
  return `$${(cents / 100).toFixed(2)}`;
}

// @ts-expect-error -- the API used to send stringserror TS2578: Unused '@ts-expect-error' directive.
formatPrice(1999);
A @ts-expect-error left behind after the error was fixed.
jsconfig.json for this example 
{
  "compilerOptions": {
    "checkJs": true,
    "noEmit": true,
    "strict": true,
    "target": "es2022",
    "module": "nodenext",
    "types": []
  },
  "include": ["*.js"]
}

What causes it

  • The error the comment was written for has been fixed, by a code change, a better type, or a new version of a library's types.
  • The comment is not directly above the line with the error (a blank line or another statement in between), so it applies to a line that is fine.

How to fix it

Remove the comment

Delete the directive. Keep @ts-expect-error only where an error is the expected result, such as a test that a function rejects the wrong type.

price.js TypeScript 5.9.3 TypeScript 5.9.3, run 21 October 2026: No errors. 6.0.3 TypeScript 6.0.3, run 21 October 2026: the same as 5.9.3. No errors. 7.0.2 TypeScript 7.0.2, run 21 October 2026: the same as 5.9.3. No errors. checked 21 October 2026 
/** @param {number} cents */
export function formatPrice(cents) {
  return `$${(cents / 100).toFixed(2)}`;
}

formatPrice(1999);

// @ts-expect-error -- a test that the type rejects strings
formatPrice("1999");
The directive removed, and one that still has an error to expect.
jsconfig.json for this example 
{
  "compilerOptions": {
    "checkJs": true,
    "noEmit": true,
    "strict": true,
    "target": "es2022",
    "module": "nodenext",
    "types": []
  },
  "include": ["*.js"]
}

Gotchas

  • Write the directive as a // comment on the line above. A /* @ts-expect-error */ block comment at the end of a line of code does not cover that line: like the // form, it applies to the line after it; the directive page shows the placement rules.
  • Text after the directive (// @ts-expect-error -- reason) is allowed and is a good place to say why.

  • Comment directive

    // @ts-expect-error

    // @ts-expect-error silences the errors on the next line, and reports TS2578 once that line has none, so a fixed problem cannot leave a stale comment.

  • Comment directive

    // @ts-ignore

    // @ts-ignore silences every error on the next line, now and later. Prefer // @ts-expect-error, which tells you when there is nothing left to silence.

  • Comment directive

    // @ts-check

    // @ts-check at the top of a .js file turns on type checking for that one file, even with checkJs off. Where to put it, and when to use it instead of checkJs.

Sources

Last reviewed 20 October 2026.