Understanding @ts-ignore and When You Should Use It

TypeScript’s type system catches errors before they reach production, but sometimes you need to tell the compiler to look the other way. That’s where @ts-ignore comes in—a TypeScript directive that suppresses compiler errors for the next line of code. While it can be a lifesaver in specific situations, using it carelessly undermines the very type safety TypeScript provides.

This article explains what @ts-ignore does, how it differs from the safer @ts-expect-error alternative, and when (if ever) you should reach for these TypeScript directives in your codebase.

What @ts-ignore Does in TypeScript

The @ts-ignore directive is a comment that tells the TypeScript compiler to skip type checking for the following line:

// @ts-ignore
const result: number = "this is actually a string"

Without the directive, TypeScript would throw a compiler error because you’re assigning a string to a variable typed as a number. With @ts-ignore, the error disappears—permanently and silently.

This behavior makes @ts-ignore particularly dangerous. Once added, it provides no feedback if the underlying issue gets fixed. The directive remains in your code, potentially hiding new TypeScript compiler errors that arise from future changes.

@ts-ignore vs @ts-expect-error: A Critical Difference

TypeScript 3.9 introduced @ts-expect-error, a safer alternative to @ts-ignore. The key difference? @ts-expect-error fails the build if no error exists on the next line:

// Using @ts-ignore (risky)
// @ts-ignore
const value: string = getUserName() // Silent even after fixing getUserName()

// Using @ts-expect-error (safer)
// @ts-expect-error
const value: string = getUserName() // Throws "Unused '@ts-expect-error' directive" when fixed

This self-documenting behavior makes @ts-expect-error superior for TypeScript best practices. It forces you to remove the directive once the underlying issue is resolved, maintaining type safety across your codebase.

When @ts-ignore Might Be Acceptable

Despite its risks, there are rare scenarios where @ts-ignore serves a legitimate purpose:

Working with Legacy Code

When migrating JavaScript to TypeScript, you might encounter complex legacy patterns that are difficult to type correctly:

// @ts-ignore - Legacy validation logic, refactoring planned for Q2
return legacyValidator.validateWithCustomRules(data, rules)

Third-Party Libraries Without Types

Some npm packages lack TypeScript definitions, and creating comprehensive types isn’t always feasible:

// @ts-ignore - No @types package available for ancient-library@1.0.0
import { processData } from 'ancient-library'

Temporary Migration Fixes

During large-scale refactoring, you might need to ship working code before completing type updates:

// @ts-ignore - Temporary: Remove after completing User type migration (JIRA-1234)
const user = getOldUserFormat()

The Hidden Costs of Overusing @ts-ignore

Every @ts-ignore in your codebase is technical debt. Here’s what you risk:

// ❌ Bad: Hiding a real bug
// @ts-ignore
const total = calculatePrice(items, "invalid-discount-type")

// ✅ Better: Fix the actual issue
const total = calculatePrice(items, DiscountType.PERCENTAGE)

Suppressing TypeScript compiler errors means:

• Runtime bugs that TypeScript would have caught
• Harder refactoring as types become unreliable
• Reduced IDE autocomplete and IntelliSense support
• Confusion for team members who can’t trust the types

Enforcing Better Practices with ESLint

The TypeScript ESLint plugin provides rules to manage directive usage:

{
  "rules": {
    "@typescript-eslint/prefer-ts-expect-error": "error",
    "@typescript-eslint/ban-ts-comment": [
      "error",
      {
        "ts-ignore": "allow-with-description",
        "minimumDescriptionLength": 10
      }
    ]
  }
}

This configuration requires explanatory comments and encourages @ts-expect-error over @ts-ignore, making TypeScript directives more intentional and trackable.

Better Alternatives to Consider First

Before reaching for @ts-ignore, try these approaches:

// Option 1: Type assertions (when you know more than TypeScript)
const element = document.getElementById('my-id') as HTMLInputElement

// Option 2: Type guards
if (typeof value === 'string') {
  // TypeScript now knows value is a string
  console.log(value.toUpperCase())
}

// Option 3: Proper type definitions
declare module 'untyped-library' {
  export function someFunction(input: string): number
}

Conclusion

The @ts-ignore directive is TypeScript’s emergency exit—use it only when no other option exists. In almost every case, @ts-expect-error provides a safer alternative that maintains accountability in your codebase. Better yet, invest time in proper typing, type assertions, or type guards to preserve the type safety that makes TypeScript valuable.

Remember: every suppressed error is a potential bug waiting to happen. Keep your TypeScript compiler errors visible, your types honest, and your @ts-ignore usage at absolute zero whenever possible.

FAQs

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.