@ts-ignore verstehen und wann Sie es verwenden sollten

Das Typsystem von TypeScript erkennt Fehler, bevor sie in die Produktion gelangen, aber manchmal müssen Sie dem Compiler sagen, dass er wegschauen soll. Hier kommt @ts-ignore ins Spiel – eine TypeScript-Direktive, die Compiler-Fehler für die nächste Codezeile unterdrückt. Obwohl sie in bestimmten Situationen ein Lebensretter sein kann, untergräbt ein unvorsichtiger Einsatz genau die Typsicherheit, die TypeScript bietet.

Dieser Artikel erklärt, was @ts-ignore bewirkt, wie es sich von der sichereren Alternative @ts-expect-error unterscheidet und wann (wenn überhaupt) Sie zu diesen TypeScript-Direktiven in Ihrer Codebasis greifen sollten.

Was @ts-ignore in TypeScript bewirkt

Die @ts-ignore-Direktive ist ein Kommentar, der dem TypeScript-Compiler mitteilt, die Typprüfung für die folgende Zeile zu überspringen:

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

Ohne die Direktive würde TypeScript einen Compiler-Fehler werfen, weil Sie einen String einer als Zahl typisierten Variable zuweisen. Mit @ts-ignore verschwindet der Fehler – dauerhaft und stillschweigend.

Dieses Verhalten macht @ts-ignore besonders gefährlich. Einmal hinzugefügt, gibt es keine Rückmeldung, wenn das zugrunde liegende Problem behoben wird. Die Direktive bleibt in Ihrem Code und verbirgt möglicherweise neue TypeScript-Compiler-Fehler, die durch zukünftige Änderungen entstehen.

@ts-ignore vs. @ts-expect-error: Ein kritischer Unterschied

TypeScript 3.9 führte @ts-expect-error ein, eine sicherere Alternative zu @ts-ignore. Der entscheidende Unterschied? @ts-expect-error lässt den Build fehlschlagen, wenn in der nächsten Zeile kein Fehler existiert:

// Verwendung von @ts-ignore (riskant)
// @ts-ignore
const value: string = getUserName() // Bleibt stumm, auch nach Behebung von getUserName()

// Verwendung von @ts-expect-error (sicherer)
// @ts-expect-error
const value: string = getUserName() // Wirft "Unused '@ts-expect-error' directive" wenn behoben

Dieses selbstdokumentierende Verhalten macht @ts-expect-error für TypeScript Best Practices überlegen. Es zwingt Sie dazu, die Direktive zu entfernen, sobald das zugrunde liegende Problem gelöst ist, und erhält so die Typsicherheit in Ihrer gesamten Codebasis.

Wann @ts-ignore akzeptabel sein könnte

Trotz seiner Risiken gibt es seltene Szenarien, in denen @ts-ignore einen legitimen Zweck erfüllt:

Arbeit mit Legacy-Code

Bei der Migration von JavaScript zu TypeScript können Sie auf komplexe Legacy-Muster stoßen, die schwer korrekt zu typisieren sind:

// @ts-ignore - Legacy-Validierungslogik, Refactoring für Q2 geplant
return legacyValidator.validateWithCustomRules(data, rules)

Drittanbieter-Bibliotheken ohne Typen

Einige npm-Pakete verfügen nicht über TypeScript-Definitionen, und das Erstellen umfassender Typen ist nicht immer machbar:

// @ts-ignore - Kein @types-Paket verfügbar für ancient-library@1.0.0
import { processData } from 'ancient-library'

Temporäre Migrations-Fixes

Während umfangreicher Refactorings müssen Sie möglicherweise funktionierenden Code ausliefern, bevor Sie die Typ-Updates abschließen:

// @ts-ignore - Temporär: Nach Abschluss der User-Typ-Migration entfernen (JIRA-1234)
const user = getOldUserFormat()

Die versteckten Kosten der übermäßigen Verwendung von @ts-ignore

Jedes @ts-ignore in Ihrer Codebasis ist technische Schuld. Folgendes riskieren Sie:

// ❌ Schlecht: Einen echten Bug verstecken
// @ts-ignore
const total = calculatePrice(items, "invalid-discount-type")

// ✅ Besser: Das eigentliche Problem beheben
const total = calculatePrice(items, DiscountType.PERCENTAGE)

Das Unterdrücken von TypeScript-Compiler-Fehlern bedeutet:

• Laufzeitfehler, die TypeScript erkannt hätte
• Schwierigeres Refactoring, da Typen unzuverlässig werden
• Reduzierte IDE-Autovervollständigung und IntelliSense-Unterstützung
• Verwirrung für Teammitglieder, die den Typen nicht vertrauen können

Bessere Praktiken mit ESLint durchsetzen

Das TypeScript ESLint-Plugin bietet Regeln zur Verwaltung der Direktiven-Nutzung:

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

Diese Konfiguration erfordert erklärende Kommentare und bevorzugt @ts-expect-error gegenüber @ts-ignore, wodurch TypeScript-Direktiven gezielter und nachverfolgbarer werden.

Bessere Alternativen, die Sie zuerst in Betracht ziehen sollten

Bevor Sie zu @ts-ignore greifen, probieren Sie diese Ansätze:

// Option 1: Type Assertions (wenn Sie mehr wissen als TypeScript)
const element = document.getElementById('my-id') as HTMLInputElement

// Option 2: Type Guards
if (typeof value === 'string') {
  // TypeScript weiß jetzt, dass value ein String ist
  console.log(value.toUpperCase())
}

// Option 3: Ordnungsgemäße Typdefinitionen
declare module 'untyped-library' {
  export function someFunction(input: string): number
}

Fazit

Die @ts-ignore-Direktive ist TypeScripts Notausgang – verwenden Sie sie nur, wenn keine andere Option existiert. In fast jedem Fall bietet @ts-expect-error eine sicherere Alternative, die die Verantwortlichkeit in Ihrer Codebasis aufrechterhält. Noch besser: Investieren Sie Zeit in ordnungsgemäße Typisierung, Type Assertions oder Type Guards, um die Typsicherheit zu bewahren, die TypeScript wertvoll macht.

Denken Sie daran: Jeder unterdrückte Fehler ist ein potenzieller Bug, der darauf wartet, zu passieren. Halten Sie Ihre TypeScript-Compiler-Fehler sichtbar, Ihre Typen ehrlich und Ihre @ts-ignore-Verwendung wann immer möglich bei absolut null.

Häufig gestellte Fragen

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.