Warum ein einziges any eine ganze Kette entwertet

unknown ist any mit einer Schranke davor

Beide Typen nehmen jeden Wert entgegen, das ist die Gemeinsamkeit. Der Unterschied liegt beim Herausgehen: Aus einem any darfst du alles machen, aus einem unknown zunächst nichts. Kein Zugriff auf Eigenschaften, kein Aufruf, keine Zuweisung an einen engeren Typ. Der Compiler zwingt dich damit an genau eine Stelle, an der du festlegst, was der Wert ist. Diese eine Stelle ist der ganze Gewinn, denn sie ist auffindbar, während ein any über zehn Dateien verteilt liegt.

Verengen kannst du auf mehreren Wegen. Für einfache Fälle reichen typeof und instanceof, weil TypeScript beide versteht und den Typ im nachfolgenden Block automatisch einschränkt. Für Objekte brauchst du eine ausdrückliche Prüfung, die auch das Ergebnis von typeof null berücksichtigt: typeof wert === 'object' && wert !== null. Danach kommst du mit dem in-Operator an die Felder, also 'kundennummer' in wert. Das ist umständlicher als ein Punkt, aber es ist genau die Arbeit, die vorher niemand gemacht hat.

Typwächter und Zusicherungsfunktionen

Ein Typwächter ist eine gewöhnliche Funktion mit einem besonderen Rückgabetyp: function istKunde(wert: unknown): wert is Kunde. Wo sie true liefert, behandelt der Compiler den Wert im folgenden Block als Kunde. Der entscheidende Punkt: Der Compiler prüft nicht, ob dein Rumpf diese Behauptung wirklich trägt. Eine Funktion, die nur typeof wert === 'object' zurückgibt, aber Kunde verspricht, ist ein as any mit besserer Tarnung. Schreib deshalb die Prüfungen aus, und zwar für die Felder, auf die der Code danach tatsächlich zugreift.

Für den Fall, dass es kein sinnvolles Weiter gibt, nimmst du eine Zusicherungsfunktion: function pruefeKunde(wert: unknown): asserts wert is Kunde. Sie wirft, wenn etwas nicht stimmt, und danach gilt der Typ für den Rest des Blocks, ohne dass du eine if-Verzweigung brauchst. Eine Eigenheit kostet regelmäßig eine Viertelstunde: Zusicherungsfunktionen brauchen am Aufrufziel eine ausdrückliche Typangabe. Eine als const gespeicherte Pfeilfunktion ohne eigene Typannotation lehnt der Compiler mit der Begründung ab, dass der Name keine ausdrücklich deklarierte Signatur hat. Als normale Funktionsdeklaration mit dem Schlüsselwort function funktioniert derselbe Code sofort.

Schemas an der Systemgrenze

Bei einer Antwort mit zwanzig Feldern wird der handgeschriebene Typwächter selbst zur Fehlerquelle, weil er neben dem Typ gepflegt werden muss und dabei auseinanderläuft. Der übliche Ausweg sind Bibliotheken zur Schemaprüfung wie zod oder valibot: Du beschreibst die Struktur einmal, bekommst daraus eine Prüffunktion und leitest den TypeScript-Typ aus demselben Schema ab. Ändert sich das Schema, ändert sich der Typ mit, und Prüfung und Deklaration können gar nicht mehr auseinanderfallen.

Die Kosten dieser Lösung sind real und überschaubar: eine Abhängigkeit mehr und eine Prüfung zur Laufzeit, die Rechenzeit braucht. Deshalb gehört sie an die Ränder und nicht in jede interne Funktion. Sinnvolle Ränder sind Antworten fremder Dienste, Formulardaten, Werte aus dem lokalen Speicher des Browsers, Konfigurationsdateien und Umgebungsvariablen. Innerhalb des eigenen Systems reichen die statischen Typen, denn dort hast du beide Seiten unter Kontrolle.

Ein Sonderfall verdient eine Absprache im Team: Antworten aus einer eigenen, ebenfalls typisierten Schnittstelle. Dort ist die Versuchung groß, die Antwort einfach zuzusichern, weil man den Vertrag ja kennt. Das trägt genau so lange, wie beide Seiten gemeinsam ausgeliefert werden. Sobald Frontend und Backend getrennt veröffentlicht werden, ist die Zusicherung eine Annahme über eine Version, die gerade läuft, und keine Aussage über die, die morgen läuft.

Bestehende Vorkommen finden und abbauen

noImplicitAny findet nur die stillschweigenden Fälle, also Parameter und Variablen ohne Typangabe. Die ausdrücklich hingeschriebenen any bleiben davon unberührt, dafür brauchst du eine Linter-Regel. In typescript-eslint heißt sie no-explicit-any. Deutlich aufschlussreicher ist allerdings die Familie no-unsafe-assignment, no-unsafe-member-access, no-unsafe-call, no-unsafe-return und no-unsafe-argument: Diese Regeln melden nicht das any selbst, sondern jede Stelle, an der ein ungeprüfter Wert weiterverwendet wird. Damit siehst du erstmals, wie weit eine einzelne Quelle ausstrahlt. Voraussetzung ist eine typbewusste Linter-Konfiguration, die das Projekt beim Prüfen mitlädt, und die läuft spürbar langsamer.

Für eine Zahl, die sich verfolgen lässt, gibt es das Werkzeug type-coverage. Es meldet den Anteil der Ausdrücke im Projekt, die einen echten Typ haben. Der absolute Wert sagt wenig, die Richtung sagt alles: Du legst den aktuellen Stand als Untergrenze im Build fest und ziehst sie nach, wenn sie steigt. Damit kann der Anteil nicht mehr zurückfallen, ohne dass es auffällt.

Beim Abbauen lohnt eine Reihenfolge. Zuerst die Quellen, also die Stellen, an denen any entsteht, denn eine einzige davon trocknet oft zwanzig Folgestellen aus. Danach die Zusicherungen mit as any, die fast immer eine Notlösung waren und häufig durch einen kleinen Zwischentyp ersetzt werden können. Ganz zum Schluss die Fälle, in denen any tatsächlich richtig ist, etwa in einer sehr allgemeinen Protokollierungsfunktion. Die dürfen bleiben, sollten aber einen Kommentar tragen, damit sie beim nächsten Durchgang nicht erneut jemanden beschäftigen.