TypeScript 7 ist nativ: Warum Microsoft den Compiler in Go neu geschrieben hat
TL;DR: TypeScript 7 ersetzt die bisherige JavaScript-basierte Werkzeugkette durch eine native Go-Implementierung und verkürzt große Builds erheblich – ist aber noch nicht für jedes Framework ein problemloser Umstieg.
Microsoft hat am 8. Juli 2026 TypeScript 7 veröffentlicht. Die neue Version ist keine gewöhnliche Weiterentwicklung des Compilers: Das TypeScript-Team hat Compiler und Sprachwerkzeuge weitgehend in Go neu implementiert.
Für Entwickler bleibt TypeScript dieselbe Sprache. Geändert hat sich die technische Grundlage der Werkzeuge, die Quellcode analysieren, Typen prüfen und Editoren mit Diagnosen, Navigation und Autovervollständigung versorgen.
TypeScript verlässt JavaScript – aber nur intern
TypeScript entstand als typisierte Erweiterung von JavaScript. Der bisherige Compiler war selbst in TypeScript geschrieben und wurde als JavaScript ausgeführt – ein klassischer Fall von Bootstrapping, bei dem eine Sprache ihre eigenen Werkzeuge implementiert.
Mit TypeScript 7 wechselt die Implementierung zu Go. Der Grund ist nicht, dass JavaScript oder TypeScript für Anwendungen ungeeignet wären. Microsoft wollte vielmehr native Ausführung, gemeinsamen Speicher und Parallelisierung nutzen, um sehr große Codebasen schneller zu analysieren.
Das Team bezeichnet die neue Implementierung als möglichst originalgetreuen Port. Struktur und Logik des bisherigen Compilers wurden weitgehend übertragen, damit identischer TypeScript-Code möglichst dieselben Ergebnisse liefert.
Die provokante Aussage „TypeScript musste JavaScript verlassen“ trifft deshalb nur auf das Werkzeug selbst zu. Entwickler schreiben weiterhin .ts- und .tsx-Dateien. Auch der erzeugte JavaScript-Code und das grundlegende Typsystem bleiben vertraut.
Warum TypeScript für Softwarequalität relevant ist
JavaScript erlaubt schnelle Entwicklung und läuft auf einer enormen Zahl von Plattformen. Seine dynamische Natur verschiebt jedoch viele Fehler in die Laufzeit: Ein falscher Datentyp, ein umbenanntes Feld oder eine nicht behandelte Variante fällt möglicherweise erst während der Ausführung auf.
TypeScript ergänzt statische Typprüfung. Fehler können dadurch bereits im Editor oder während des Builds sichtbar werden. Typen dokumentieren Datenstrukturen und Schnittstellen direkt im Code. Refactorings werden nachvollziehbarer, weil Werkzeuge Abhängigkeiten erkennen und Änderungen prüfen können.
Das garantiert keine gute Software. Falsch modellierte Typen, großzügiger Einsatz von any, fehlende Tests und schlechte Architektur bleiben auch in TypeScript möglich. Statische Typisierung schließt aber eine wichtige Lücke zwischen der Flexibilität von JavaScript und den Sicherheitsnetzen klassisch typisierter Sprachen.
ScalerIT setzt deshalb seit Jahren bei JavaScript-basierten Projekten konsequent auf TypeScript. Der Nutzen liegt weniger in einzelnen Fehlermeldungen als in der langfristigen Wartbarkeit: Schnittstellen werden explizit, Änderungen besser überprüfbar und große Codebasen für Menschen wie Entwicklungswerkzeuge verständlicher.
Geschwindigkeit ist Teil der Codequalität
Eine Typprüfung hilft nur, wenn sie regelmäßig stattfindet. Dauert der vollständige Check mehrere Minuten, verschiebt sich Feedback in die CI-Pipeline. Entwickler arbeiten länger mit fehlerhaften Annahmen und erfahren erst spät, ob eine Änderung andere Bereiche beschädigt.
TypeScript 7 will diese Rückkopplung verkürzen. Microsoft nennt für vollständige Builds typischerweise eine Beschleunigung um den Faktor acht bis zwölf. In den veröffentlichten Messungen sank die Buildzeit des VS-Code-Projekts von 125,7 auf 10,6 Sekunden. Sentry fiel von 139,8 auf 15,7 Sekunden, Playwright von 12,8 auf 1,47 Sekunden.
Das sind Messungen des TypeScript-Teams auf ausgewählten großen Projekten und keine Garantie für jede Anwendung. Kleinere Codebasen, CI-Systeme mit wenigen CPU-Kernen oder Projekte mit anderen Engpässen können deutlich weniger profitieren. Dennoch zeigen die Werte, welchen Einfluss Compilerarchitektur auf den Entwicklungsalltag haben kann.
Microsoft berichtet außerdem über geringeren Speicherbedarf in den getesteten Projekten. Beim Öffnen einer fehlerhaften Datei im VS-Code-Codebestand sank die Zeit bis zur ersten Diagnose laut Ankündigung von etwa 17,5 auf weniger als 1,3 Sekunden. Alle Zahlen und Testprojekte stehen in der offiziellen Veröffentlichung von TypeScript 7.
Parallelisierung verändert den Compiler
Ein zentraler Vorteil der neuen Implementierung ist die Nutzung mehrerer Threads. TypeScript 7 erzeugt standardmäßig mehrere Type-Checker-Prozesse, die Teile der Analyse parallel durchführen.
Das ist schwieriger, als Dateien lediglich auf verschiedene CPU-Kerne zu verteilen. Typen hängen über Importe, Generics und Deklarationen hinweg voneinander ab. Gleichzeitig müssen identische Eingaben weiterhin reproduzierbare Ergebnisse erzeugen.
TypeScript 7 verwendet standardmäßig vier Checker. Über --checkers lässt sich die Zahl anpassen. Mehr Worker können große Builds weiter beschleunigen, benötigen aber zusätzlichen Speicher und doppeln teilweise Arbeit. Auf kleinen CI-Runnern kann eine niedrigere Einstellung daher sinnvoller sein.
Teams sollten diese Option messen, nicht pauschal maximieren. Der schnellste Wert auf einem Entwickler-Mac muss nicht zum preiswertesten oder stabilsten CI-Setup führen.
Auch der Editor bekommt eine neue Grundlage
TypeScript besteht nicht nur aus tsc. Der Language Server beantwortet Editoranfragen: Autovervollständigung, Definitionen, Referenzen, Umbenennungen, Fehleranzeigen und Typinformationen.
TypeScript 7 verwendet dafür das standardisierte Language Server Protocol, kurz LSP. Dadurch lässt sich die Sprachunterstützung leichter in unterschiedliche Editoren integrieren. Die neue Architektur kann zudem mehrere Anfragen parallel bearbeiten.
Microsoft gibt an, dass fehlgeschlagene Language-Server-Kommandos gegenüber TypeScript 6 um mehr als 80 Prozent und Abstürze um mehr als 60 Prozent zurückgegangen seien. Diese Telemetriedaten stammen vom Hersteller, zeigen aber, dass der Port nicht nur auf Geschwindigkeit, sondern auch auf Stabilität zielt.
VS Code unterstützt TypeScript 7 zunächst über eine eigene Erweiterung; die Integration soll Bestandteil des Editors werden. Andere moderne Editoren können den LSP-basierten Server ebenfalls anbinden, müssen dafür aber ihre jeweilige Unterstützung aktualisieren.
Noch kein universeller Drop-in-Ersatz
Trotz der finalen Versionsnummer ist TypeScript 7 nicht für jedes Projekt sofort die richtige Wahl. Die wichtigste Einschränkung: Version 7.0 liefert noch keine stabile programmgesteuerte Compiler-API aus.
Werkzeuge, die TypeScript intern als Bibliothek einbetten, benötigen deshalb vorerst TypeScript 6. Das betrifft unter anderem Teile des Ökosystems rund um typescript-eslint.
Besonders relevant ist die Einschränkung für Frameworks und Formate mit eingebetteten Sprachen. Vue, Svelte, Astro, MDX und ähnliche Werkzeuge integrieren TypeScript in eigene Compiler und Language Server. Auch die spezielle Template-Prüfung von Angular hängt von entsprechenden APIs ab. Laut TypeScript-Team können diese Workflows TypeScript 7 teilweise noch nicht vollständig nutzen.
Für manche Projekte ist ein Mischbetrieb möglich: TypeScript 7 übernimmt die schnelle Kommandozeilenprüfung, während Editor-Plugins oder spezialisierte Werkzeuge weiterhin TypeScript 6 verwenden. Für Vue-, Svelte-, Astro- und MDX-Projekte empfiehlt Microsoft derzeit teilweise, zunächst vollständig bei TypeScript 6 zu bleiben.
Eine neue API ist für TypeScript 7.1 angekündigt. Sie soll anders aussehen als die bisherige Schnittstelle, weshalb Toolhersteller ihre Integrationen anpassen müssen.
TypeScript 6 ist die Brücke
TypeScript 7 orientiert sich am Verhalten von TypeScript 6. Deshalb empfiehlt das Team, zunächst sauber auf Version 6 zu migrieren.
Version 7 aktiviert strengere und modernere Vorgaben. strict ist standardmäßig eingeschaltet, module verwendet standardmäßig esnext, und das Target orientiert sich an einer aktuellen ECMAScript-Version. Veraltete Optionen, die TypeScript 6 noch übergangsweise akzeptiert, führen in TypeScript 7 zu Fehlern.
Code, der unter TypeScript 6 mit stabiler Typreihenfolge und ohne unterdrückte Deprecation-Warnungen kompiliert, sollte nach Aussage des Teams in TypeScript 7 weitgehend identische Ergebnisse liefern.
Für Abhängigkeiten, die weiterhin die alte Compiler-API benötigen, stellt Microsoft @typescript/typescript6 bereit. Damit können Version 6 und 7 kontrolliert nebeneinander installiert werden.
Ein sinnvoller Migrationsweg
Der erste Schritt ist ein reproduzierbarer Ausgangswert. Teams sollten aktuelle Buildzeiten, Editorstart, CI-Dauer und Speicherverbrauch messen. Sonst lässt sich später kaum beurteilen, ob der Wechsel tatsächlich hilft.
Danach sollte das Projekt auf TypeScript 6 aktualisiert und von veralteten Optionen bereinigt werden. Erst wenn dieser Stand stabil ist, folgt ein separater Test mit Version 7.
Besondere Aufmerksamkeit verdienen ESLint-Integration, Framework-Compiler, Codegeneratoren, API Extractor, Dokumentationswerkzeuge und eigene Skripte, die das typescript-Paket importieren. Ein erfolgreiches tsc allein beweist noch nicht, dass die gesamte Toolchain kompatibel ist.
Anschließend sollten CI und lokale Entwicklung getrennt optimiert werden. Die Zahl der Checker, verfügbare CPU-Kerne und Speichergrenzen unterscheiden sich häufig. Ein kontrollierter Pilot in einem einzelnen Repository ist sinnvoller als ein gleichzeitiges Upgrade aller Projekte.
Kontext
TypeScript wurde seit seiner Veröffentlichung 2012 zu einer zentralen Grundlage moderner Web-, Server- und App-Entwicklung. Der native Port ist kein Wechsel der Anwendungssprache, sondern eine Neuimplementierung ihrer Entwicklungswerkzeuge – vergleichbar mit einem Motorwechsel, bei dem Bedienung und Ziel gleich bleiben, aber Leistung und innere Architektur grundlegend verändert werden.
Was als Nächstes zählt
In den kommenden Monaten wird entscheidend sein, wie schnell Frameworks, Linter und Buildwerkzeuge die neue API übernehmen. TypeScript 7.1 ist deshalb für viele Teams möglicherweise der wichtigere Migrationspunkt als 7.0.
Projekte ohne komplexe Compiler-Integration können TypeScript 7 bereits heute in einem Branch oder einer isolierten CI-Stufe testen. Teams mit Angular, Vue, Svelte, Astro oder umfangreichen TypeScript-API-Abhängigkeiten sollten den Mischbetrieb und die jeweilige Herstellerunterstützung genau prüfen.
Der größte Gewinn liegt nicht allein in einer kürzeren Buildzeit. Schnelle Typprüfung bringt Feedback dorthin zurück, wo es am wertvollsten ist: direkt in den Arbeitsablauf des Entwicklers, bevor ein Fehler zum CI-Problem oder zur Laufzeitüberraschung wird.