DE
RU
EN
ES
ZH
FR
PT
AR
HI
Stille im Editor: Warum sollten wir TypeScript blockieren?
\n\nJeder, der auch nur eine Woche mit TypeScript gearbeitet hat, kennt die Situation, in der der Compiler anfängt, auf scheinbar funktionierenden Code zu „schimpfen". Sie sind sich sicher, dass die Logik korrekt ist, aber tsc oder die IDE markieren jede zweite Zeile rot. Besonders schmerzhaft ist es, wenn dies innerhalb eines Blocks passiert: einer Schleife, einer Bedingung oder einer Funktion.
Das Standard-// @ts-ignore funktioniert nur für die nächste Zeile. Was aber, wenn man den Compiler für 10–15 Zeilen auf einmal „zum Schweigen bringen" muss? Denselben Kommentar vor jede Zeile zu kopieren, führt in eine Sackgasse. Das verschmutzt nicht nur den Code, sondern macht ihn auch unlesbar.
In diesem Artikel betrachten wir drei praktische Ansätze, wie man @ts-ignore für einen gesamten Block in TypeScript anwenden kann. Sie erfahren, wann jeder davon angemessen ist und wann man besser ganz auf die Unterdrückung von Fehlern verzichtet. Los geht's!
Problem: @ts-ignore funktioniert nur für eine Zeile
\n\nBeginnen wir mit einem einfachen Beispiel. Stellen Sie sich vor, Sie arbeiten mit dynamischen Daten aus einer API, deren Typen sich ändern können. Sie haben einen Codeblock, der definitiv ausgeführt wird, aber TypeScript bemängelt jeden Zugriff auf eine Eigenschaft.
\n\n// Beispiel: Parsen einer Antwort von einer unzuverlässigen API\nconst data: any = { user: { name: 'Alice', age: 30 } };\n\n// @ts-ignore\nconsole.log(data.user.name); // OK, aber nur eine Zeile\n\n// Die nächste Zeile verursacht erneut einen Fehler, wenn // @ts-ignore nicht hinzugefügt wird\n// console.log(data.user.age); // Error: Property 'age' does not exist on type 'object'\nVor jeder Zeile // @ts-ignore zu schreiben, ist eine schlechte Praxis. Es erhöht den Codeumfang, erschwert das Refactoring und verbirgt echte Fehler. Aber es gibt gute Nachrichten: TypeScript (ab Version 3.9) und die Community haben mehrere elegante Lösungen entwickelt.
Ansatz 1: @ts-nocheck — rohe Gewalt für die gesamte Datei
\n\nDer einfachste, aber auch radikalste Weg ist, // @ts-nocheck am Anfang der Datei hinzuzufügen. Dies deaktiviert die Typüberprüfung für die gesamte Datei vollständig. Aber wir brauchen einen Block, nicht die ganze Datei. Es gibt jedoch einen Trick: Man kann den problematischen Block in eine separate Datei auslagern und importieren.
Vorteile:
\n- \n
- Löst das Problem sofort. \n
- Geeignet für Legacy-Code, den Sie später umschreiben möchten. \n
Nachteile:
\n- \n
- Deaktiviert alle Typüberprüfungen in der Datei. Sie könnten echte Fehler übersehen. \n
- Nicht geeignet für große Projekte mit strengen Linting-Regeln. \n
- Erzeugt „Black Boxes" aus Code. \n
// bad.ts — Datei mit deaktivierter Überprüfung\n// @ts-nocheck\nexport function processData(data: any) {\n const result = data.user.name + ' is ' + data.user.age;\n return result; // Es wird keinen Fehler geben, selbst wenn data — null ist\n}\nWann verwenden: Nur für temporäre Skripte oder vererbten Code, den Sie umschreiben. Verwenden Sie es niemals in der Produktion ohne einen expliziten TODO-Vermerk.
Ansatz 2: ts-expect-error — die intelligente Alternative zu @ts-ignore
\n\nSeit TypeScript 3.9 gibt es die Direktive // @ts-expect-error. Sie funktioniert fast wie @ts-ignore, aber mit einem wichtigen Unterschied: Wenn kein Fehler vorliegt, gibt TypeScript eine Warnung aus. Dies hilft, nicht zu vergessen, den Kommentar nach der Korrektur des Codes zu entfernen.
Aber wie wendet man das auf einen Block an? Die Antwort — gar nicht direkt. @ts-expect-error funktioniert ebenfalls nur für eine Zeile. Wir können jedoch einen Trick mit einem sofort aufgerufenen Funktionsausdruck (IIFE) anwenden.
// Der zu ignorierende Block, in ein IIFE verpackt\n(function() {\n // @ts-expect-error — wir erwarten einen Fehler in der nächsten Zeile\n const x: number = 'hello'; // Error: Type 'string' is not assignable to type 'number'\n\n // @ts-expect-error — ein weiterer erwarteter Fehler\n con 
