JS with Types Start

Comment directive

// @ts-expect-error

  • Applies to the next line
  • Since TypeScript 3.9

// @ts-expect-error on its own line says "the next line has an error, on purpose". TypeScript silences the errors on that line, and if the line has none, it reports the comment itself: TS2578, "Unused '@ts-expect-error' directive". It arrived with TypeScript 3.9.

That makes it the safe way to keep a known error for now: when someone fixes the line, the comment fails npm run lint and gets removed, instead of lingering to hide the next mistake the way // @ts-ignore can.

At a glance

Write // @ts-expect-error
Applies to The line after the comment
With checkJs on Silences the errors on the next line, and is itself an error (TS2578) when that line has none
With checkJs off Nothing, unless the file starts with // @ts-check

Examples

main.js Error confirmed 5.9.3 TypeScript 5.9.3, run 21 October 2026: main.js(11,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. main.js(11,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. main.js(11,1): error TS2578: Unused '@ts-expect-error' directive. checked 21 October 2026 
/** @param {number} cents */
function formatPrice(cents) {
  return `$${(cents / 100).toFixed(2)}`;
}

// @ts-expect-error: the old API passed strings
console.log(formatPrice("1999"));

// This call was fixed, so the directive above it now has nothing to silence.
// @ts-expect-errorerror TS2578: Unused '@ts-expect-error' directive.
console.log(formatPrice(1999));
// @ts-expect-error twice: one silences a real error, the other is reported because its line has none.
jsconfig.json for this example 
{
  "compilerOptions": {
    "checkJs": true,
    "noEmit": true,
    "strict": true,
    "target": "es2022",
    "module": "nodenext",
    "types": []
  },
  "include": [
    "*.js"
  ]
}

Say why

Text after the directive on the same line is ignored by the checker, so write the reason there: // @ts-expect-error: the old API passed strings. The first call in the example does exactly that.

It has to be on the line above

The directive applies to the line that follows it. A block comment at the start of the same line, /* @ts-expect-error */ formatPrice("1"), does not count: in TypeScript 5.9 the error on that line is still reported, and so is the directive, as unused.

Gotchas

  • Tests that check a function rejects bad input are the classic use: // @ts-expect-error above formatPrice("1999") in a test file documents the type and proves it still holds.
  • In a file that is not checked (no checkJs, no // @ts-check) the comment does nothing and is never reported.

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

  • jsconfig.json option

    checkJs

    checkJs turns on TypeScript's error reporting for .js files. What it checks, how it relates to allowJs and // @ts-check, and how to switch it on.

  • TypeScript error

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

    TS2578 means a // @ts-expect-error comment sits above a line that no longer has an error. Remove the comment; that is the directive doing its job.

Sources

Last reviewed 20 October 2026.