strict im Bestand: was es kostet und was es bringt

Was strict überhaupt einschaltet

strict ist kein eigener Modus, sondern ein Sammelschalter für neun Einzelprüfungen: alwaysStrict, noImplicitAny, noImplicitThis, strictBindCallApply, strictBuiltinIteratorReturn, strictFunctionTypes, strictNullChecks, strictPropertyInitialization und useUnknownInCatchVariables. strictBuiltinIteratorReturn ist mit TypeScript 5.6 dazugekommen, und das ist kein Einzelfall: Unter strict können weitere Prüfungen nachrücken, ein Sprung auf eine neue Compiler-Version kann also neue Meldungen bringen. Wichtig für den Bestand ist, dass sich jede dieser Prüfungen einzeln übersteuern lässt. Du kannst also strict auf true setzen und darunter strictNullChecks vorübergehend auf false, statt alles gemeinsam abzuwarten. Damit sicherst du die einfacheren Prüfungen sofort und nimmst dir die aufwendigste getrennt vor.

Nicht in strict enthalten sind einige Optionen, die im Gespräch oft dazugezählt werden: noUncheckedIndexedAccess, exactOptionalPropertyTypes, noImplicitOverride, noPropertyAccessFromIndexSignature sowie die Aufräumhilfen noUnusedLocals und noUnusedParameters. Vor allem noUncheckedIndexedAccess ist eine eigene Entscheidung mit spürbaren Folgen, weil danach jeder Zugriff über einen Index oder einen dynamischen Schlüssel auch undefined liefern kann. Das ist fachlich richtig und erzeugt in Code, der viel mit Listen und Nachschlagetabellen arbeitet, noch einmal eine eigene Welle.

Warum strictNullChecks alleine steht

Ohne diese Prüfung sind null und undefined Mitglieder jedes Typs. Ein string kann also ohne Beanstandung null sein, und jede Zusicherung im Code ist damit eine Behauptung ohne Deckung. Mit der Prüfung werden beide zu eigenen Typen, die ausdrücklich in einer Vereinigung stehen müssen. Genau deshalb erzeugt sie den Großteil aller Meldungen und lässt sich nicht in kleinen Häppchen einführen: Sobald sie an ist, betrifft sie jede Zeile, die eine Variable liest.

Der Aufwand verteilt sich dabei sehr ungleich. In reinen Rechenfunktionen passiert fast nichts. Teuer wird es an den Rändern: bei Antworten aus dem Netz, bei Zugriffen aufs DOM, bei Konfigurationswerten und überall dort, wo eine Funktion optionale Parameter hat. Deshalb lohnt es sich, vor dem Einschalten genau diese Ränder zu bereinigen, also einmal ordentlich zu typisieren, was aus dem Netz kommt. Danach fällt ein erheblicher Teil der Meldungen weg, ohne dass jemand eine einzige if-Abfrage geschrieben hätte.

Beim Reparieren gibt es einen Umweg, der teuer ist und deshalb eine Absprache verdient: das Ausrufezeichen hinter einem Ausdruck, also wert!.name. Es sagt dem Compiler, dass hier sicher kein null steht, prüft aber nichts. In wenigen Fällen ist das richtig, etwa wenn ein Element garantiert im HTML des eigenen Templates steht. Als allgemeine Antwort auf Meldungen macht es die Einführung von strict wertlos, weil das Ergebnis genau die Sicherheit vortäuscht, die vorher gefehlt hat.

Der Weg über eine zweite Konfiguration

Statt eines Stichtags legst du eine tsconfig.strict.json an, die per extends auf der bestehenden Konfiguration aufsetzt, dort strict einschaltet und in include nur die Ordner aufzählt, die schon bereinigt sind. Der normale Build läuft unverändert weiter, die strenge Prüfung startet zusätzlich mit tsc -p tsconfig.strict.json --noEmit. Wächst die Liste in include, wächst der geschützte Bereich, und niemand muss auf einen großen Umbau warten.

Diese Konstruktion hat einen Haken, den man kennen sollte: Der Compiler prüft auch Dateien, die von den eingeschlossenen importiert werden, selbst wenn sie nicht in include stehen. In der Praxis bedeutet das, dass du an den Blättern des Abhängigkeitsbaums anfängst, also bei Hilfsfunktionen und Datenmodellen ohne eigene Importe. Von dort arbeitest du dich nach oben. Wer bei einer Seitenkomponente beginnt, zieht in der ersten Runde das halbe Projekt mit hinein.

Für die Steuerung im Alltag reicht ein einziges Signal: die Zahl der Meldungen aus dem strengen Lauf, festgehalten je Woche. Sie darf nur fallen. Sobald sie steigt, ist entweder ein Ordner zu früh in include gewandert oder jemand hat in einem geschützten Bereich neue Schulden angelegt. Diese eine Zahl ersetzt jede Diskussion darüber, ob es vorangeht.

Wann sich der Aufwand für ein Team nicht lohnt

Wenn eine Anwendung nur noch Fehlerbehebungen bekommt und in absehbarer Zeit abgelöst wird, ist die Verschärfung ein Umbau ohne Empfänger. Dasselbe gilt für Code, der ohnehin generiert wird, etwa Klienten aus einer Schnittstellenbeschreibung: Dort gehört die Strenge in den Generator und nicht in die erzeugten Dateien.

Umgekehrt gibt es drei Lagen, in denen sich der Aufwand fast immer rechnet. Erstens, wenn regelmäßig neue Leute dazukommen, denn strenge Typen sind die einzige Dokumentation, die nicht veraltet. Zweitens, wenn dieselbe Datenstruktur durch viele Module fließt, weil dort ein einzelnes any die Prüfung auf dem ganzen Weg abschaltet. Und drittens, wenn du ohnehin eine größere Umbaumaßnahme vor dir hast: Ein Refactoring unter strict ist eine andere Tätigkeit als eines ohne, weil der Compiler dir die betroffenen Stellen zeigt, statt sie dir zu überlassen.