Entscheidungen bei der Aufwertung auf TypeScript 7: Parallel Checkers, Watch Mode und API-Lücken

TypeScript 7 ist eine ungewöhnliche Major-Version: Die Sprache, mit der man programmiert, bleibt unverändert, während das Programm, das sie prüft und kompiliert, ersetzt wurde. Für die meisten Teams bedeutet das Upgrade eine erhebliche Geschwindigkeitssteigerung, ohne dass etwas repariert werden muss, doch für Teams, deren Tools direkt mit dem Compiler kommunizieren, kann es ein Hindernis darstellen. Diese Anleitung erläutert, was sich tatsächlich zwischen 6 und 7 unterscheidet, wie man die neuen Parallelisierungssteuerungen verwendet und wie man entscheiden kann, ob das Projekt jetzt migriert werden soll oder auf eine weitere Version warten muss.

Der Blog hat bereits ausführlich die Geschwindigkeitsvorteile der Umstellung auf Go sowie warum die Umstellung die Linter- und Framework-Tools beeinträchtigt hat behandelt, weshalb sich der Fokus hier auf die praktische Entscheidung zur Migration legt.

Die gleiche Sprache, ein neuer Engine

Zum Zeitpunkt der Erstellung dieses Textes ist TypeScript 7.0 als stabile Version veröffentlicht worden (gemeldet am 8. Juli 2026; überprüfen Sie die Veröffentlichungsnotizen für den aktuellen Stand). Es handelt sich um eine Neuimplementierung des Compilers von TypeScript in Go, ein Projekt, das Microsoft im März 2025 unter dem Codenamen Corsa angekündigt hat. Es handelt sich dabei nicht um eine neue Sprachversion im üblichen Sinne: Es gibt keine neue Syntax, die Semantik des Typsystems soll unverändert bleiben, und es wird erwartet, dass bestehende .ts-Dateien weiterhin funktionieren. Ihr Code bleibt unverändert; nur die darunterliegende Technologie ändert sich.

Warum der Compiler neu geschrieben werden musste

Bis einschließlich TypeScript 6 war der Compiler in TypeScript geschrieben und auf einem JavaScript-Engine ausgeführt worden, was in der Praxis bedeutet hat, dass die Typüberprüfung auf einem einzigen Thread stattfand. In großen Monorepos zeigten sich diesbezüglich drei typische Probleme:

• Die Editor brauchten so lange, um ein Projekt zu laden, dass die Entwickler lernten, zu warten.
• Die Typüberprüfungen im CI dauerten pro Ausführung mehrere Minuten.
• Der Speicherverbrauch war so hoch, dass Laptops deutlich unter Last gerieten.

Das Team optimierte die JavaScript-Implementierung jahrelang und kam zu dem Schluss, dass das Engpassproblem im Laufzeitumfeld selbst lag und nicht in den Algorithmen. Deshalb wurde der Prüfer auf Go portiert, wobei bewusst darauf geachtet wurde, seine Struktur so weit wie möglich dem bestehenden Code anzupassen. Diese Entscheidung ist wichtig: Nur eine getreue Portierung und nicht ein Neuentwurf sorgen dafür, dass Abweichungen im Verhalten zwischen 6 und 7 bleiben.

Was unterscheidet sich in der Praxis

Weitaus schnellere Typüberprüfung

Die veröffentlichten Benchmarks von Microsoft zeigen das Ausmaß der Verbesserung: Die Typüberprüfung des VS Code-Codebases sank von 77,8 Sekunden auf 7,5 Sekunden – das sind etwa zehnmal schnellere Ergebnisse – und bei Playwright von 11,1 Sekunden auf 1,1 Sekunde. Zwei Faktoren tragen dazu bei. Der Compiler läuft nun als natives Maschinencode anstelle von JavaScript, das von einem Engine ausgeführt wird, und kann außerdem mithilfe von Goroutinen parallel überprüfen, was das alte eindimensionale Design niemals möglich gemacht hätte. Ihre eigenen Werte hängen von der Struktur des Projekts ab; viele kleine, unabhängige Dateien lassen sich besser parallelisieren als ein riesiges Gewirr aus Typen.

Neue Befehlszeileneingaben für die Parallelisierung

Ihr tsconfig.json ändert sich nicht, denn es beschreibt die Sprache und das Projekt, nicht jedoch, wie der Compiler seine Arbeit planen soll. Die untenstehende Konfiguration gilt für beide Versionen:

// tsconfig.json — nothing changes here, this is the language, not the compiler
{
  "compilerOptions": {
    "strict": true,
    "target": "ES2022"
  }
}

Die neuen Einstellungsregler befinden sich stattdessen in der Befehlszeile. --checkers legt fest, wie viele Typprüfer gleichzeitig ausgeführt werden, --builders steuert, wie viele Projektreferenz-Kompilierungen gleichzeitig ablaufen, und --singleThreaded deaktiviert den Parallelismus vollständig:

# But at the CLI level, TypeScript 7 gives you real knobs to turn:
tsc --checkers 4        # number of parallel type-checker workers
tsc --builders 2        # parallel project-reference builds
tsc --singleThreaded    # opt out entirely, useful for reproducible CI logs

Der Einzelthread-Modus ist nützlich, wenn man deterministische, leicht lesbare CI-Protokolle benötigt oder ein vermutetes Sortierungsproblem aufklären will. Auf gemeinsam genutzten CI-Servern verhindert das Begrenzen von --checkers auf die Anzahl der verfügbaren Kerne eine Überlastung des Systems; mehr Worker bedeuten außerdem einen höheren Speicherverbrauch gleichzeitig, daher sollte man messen anstatt blind zu maximieren.

Ein überarbeiteter Überwachungsmodus

In großen Projekten stellte der alte, auf Abfragen basierende Dateiüberwacher ein bekanntes Problem dar, da tsc --watch mit den Änderungen hinterherhinkte. TypeScript 7 überträgt den von Parcels Überwacher verwendeten Ansatz für die Dateiüberwachung auf Go, sodass Neucompilierungen unmittelbar nach der Speicherung beginnen und nicht mehr zurückbleiben.

Einfachere Verpackung

Während der Vorabversion bedeutete das Ausprobieren des nativen Compilers die Installation eines separaten Pakets @typescript/native-preview. Mit 7.0 liegt alles wieder unter dem Standard-Paketnamen, wodurch die Installation genauso aussieht wie bisher:

npm install -D typescript

Falls Sie mit der Vorabversion experimentiert haben, entfernen Sie dieses zusätzliche Paket sowie alle Skripte, die seine separate Binärdatei aufrufen, damit Sie nicht mit zwei Compilern arbeiten müssen.

Die eigentliche Lücke: die programmatische API

Dies ist der Teil, der viele Aktualisierungen bestimmt. Werkzeuge, die auf der TypeScript-Compiler-API basieren – wie z. B. Language-Service-Plugins, benutzerdefinierte Lint-Regeln und Codemods – können derzeit noch nicht auf eine stabile programmatische API für den Go-Compiler in Version 7.0 zurückgreifen; zum Zeitpunkt der Erstellung wird mit einer Veröffentlichung in einer späteren Version gerechnet, wobei 7.1 als Ziel genannt wird. Wenn Ihr Pipeline-System Funktionen wie ts.createProgram() verwendet, um das Programm zu durchlaufen, prüfen Sie diesen Weg sorgfältig, bevor Sie ihn in der Produktion einsetzen.

Ein realistisches Migrationsszenario

Betrachten Sie ein mittelgroßes Next.js-Monorepo mit etwa 40.000 Zeilen TypeScript sowie mehreren Projektreferenzen. Ein Upgrade auf Version 7.0 in einer solchen Konfiguration kann die Ausführung von tsc --noEmit von rund 52 Sekunden auf etwa 6 Sekunden verkürzen. Eine eingesparte Zeit von 46 Sekunden mag bescheiden erscheinen, doch sie gilt für jeden CI-Job, jedes pre-commit-Hook sowie jede manuelle Überprüfung während des Debuggens – im Team summieren sich diese Zeiten auf mehrere Stunden pro Woche.

Bei Projekten, die tsc ausschließlich zum Überprüfen und Kompilieren verwenden, ist die Migration an sich in der Regel enttäuschend: Man aktualisiert das Paket, führt den Überprüfer aus und stellt fest, dass er ohne Codeänderungen erfolgreich ist.

npm install -D typescript@latest
npx tsc --noEmit   # ran clean, zero code changes needed

Eine reibungslose Ausführung ist das erwartete Ergebnis, aber keine Garantie. Bewahren Sie das Ergebnis von TypeScript 6 zur Vergleichszweck auf und vergleichen Sie die gemeldeten Fehler bei der ersten Ausführung miteinander, da bei einer so großen Portion an Code immer auch Randfälle auftreten können.

Sollten Sie jetzt upgraden?

• Erweitern Sie jetzt, wenn Sie tsc nur für Typüberprüfungen und Kompilierungen verwenden. Es handelt sich dabei im Grunde um eine nahtlose Verbesserung.
• Warten oder trennen, wenn Sie auf die programmatische API des Compilers über benutzerdefinierte Tools, Editor-Plugins oder Codemods angewiesen sind. Warten Sie auf die stabile API oder behalten Sie TypeScript 6 für diese Tools bei, während Sie 7 zur Überprüfung nutzen.
• Geben Sie ihm Priorität, wenn Sie ein sehr großes Monorepo betreiben, bei dem die Zeit im CI eine echte Kostenfaktor ist. Die Zeiteinsparungen können die Migrationsanstrengungen bereits innerhalb weniger Tage ausgleichen.

Hauptpunkte

• TypeScript 7 ändert den Compiler, nicht die Sprache; Ihre tsconfig.json-Datei sowie Quelldateien bleiben unverändert.
• Die Geschwindigkeitssteigerung resultiert aus nativem Code sowie paralleler Überprüfung, die Sie mit --checkers, --builders und --singleThreaded anpassen können.

Das Hauptrisiko liegt nicht im eigenen Code, sondern in Tools, die den Compiler enthalten – überprüfen Sie diese daher vor dem Umstieg.

Falls langsame Überprüfungen Ihr größtes Manko bei TypeScript waren, beseitigt Version 7 dies weitgehend; falls Sie auf die internen Mechanismen des Compilers angewiesen sind, warten Sie noch eine weitere Version ab.