Wofür wir TypeScript einsetzen
Überall dort, wo Frontend-Code mehr ist als ein paar Zeilen Interaktion. In Astro-Projekten schreiben wir Komponenten und Datenzugriffe typisiert. In Shopware-6-Themes typisieren wir die eigenen Plugins und die Übergabe zwischen Twig und JavaScript. Bei individuellen Oberflächen — Konfiguratoren, Redaktionswerkzeugen, Dashboards hinter dem Login — ist TypeScript für uns die Voraussetzung, nicht die Kür. Kleine Skripte in einer WordPress-Seite bleiben dagegen oft schlicht JavaScript.
Den größten Effekt hat TypeScript an Schnittstellen. Wenn eine REST- oder GraphQL-API Daten liefert, beschreiben Typen die Antwort, und der Compiler meldet sich, wenn das Backend ein Feld umbenennt oder optional macht. Aus OpenAPI-Beschreibungen lassen sich diese Typen erzeugen, statt sie abzutippen. Fehler dieser Art fallen sonst erst im Browser auf — im ungünstigen Fall beim Kunden, an einem Freitagnachmittag.
Wie wir damit arbeiten
Wir fangen streng an, weil das Nachziehen teurer ist. strict ist eingeschaltet, any braucht eine Begründung, und Typen aus fremden Paketen prüfen wir, statt ihnen zu glauben. Der Compiler läuft in der Continuous Integration, nicht nur auf dem Entwicklerrechner — sonst wird der erste rote Fehler irgendwann ignoriert. Für Bestandsprojekte gilt der umgekehrte Weg: schrittweise Migration, Datei für Datei, beginnend bei den Stellen, die am häufigsten angefasst werden.
Gebaut wird mit Vite, geprüft mit ESLint und dem TypeScript-Compiler getrennt voneinander — Bundler transpilieren, sie prüfen nicht. Typen halten wir nah an den Daten: eine Quelle für Formen, die Backend und Frontend teilen, statt zweier Definitionen, die auseinanderlaufen. Und wir schreiben keine Typen, die nur den Compiler beeindrucken. Ein generisches Ungetüm, das niemand liest, ist keine Dokumentation, sondern eine zweite Sprache im Projekt.
Grenzen: was TypeScript nicht leistet
TypeScript prüft, was der Compiler sieht — und der sieht nur Ihren Code. Alles, was zur Laufzeit von außen kommt, ist zunächst eine Behauptung: API-Antworten, Formulardaten, Werte aus dem Local Storage, Inhalte aus dem CMS. Wer sie ohne Prüfung als typisiert behandelt, hat Sicherheit auf dem Papier. An diesen Rändern validieren wir zur Laufzeit, etwa mit Zod. Ein Typfehler, den niemand prüft, ist ein Laufzeitfehler mit Vorlaufzeit.
Nicht jedes Projekt braucht TypeScript. Für ein paar Zeilen in einer Landingpage steht der Aufwand für Build, Konfiguration und Typdefinitionen in keinem Verhältnis; dort schreiben wir modernes JavaScript und gut. Auch ersetzt TypeScript keine Tests. Es prüft Formen, nicht Verhalten — dass eine Preisberechnung die richtige Zahl liefert, weiß der Compiler nicht. Und wo Typen nur mit Casts durchgehen, stimmt meist das Datenmodell nicht.