TypeScript 7.0 ist 10-mal schneller und in Go geschrieben. So übernehmen Sie es, ohne CI zu brechen.

Microsoft hat am 18. Juni 2026 den TypeScript 7.0 Release Candidate veröffentlicht – die große Neuigkeit ist keine neue Syntax. Es ist der Compiler selbst. Im vergangenen Jahr portierte das Team TypeScript aus seiner eigenen, in JavaScript bootstrappten Codebasis nach Go, und das Ergebnis prüft Typen etwa 10-mal schneller als TypeScript 6.0. Die veröffentlichten Zahlen sind eindeutig: Die VS Code-Codebasis mit rund 1,5 Millionen Zeilen senkt die Typprüfungszeit von 77,8 Sekunden auf 7,5 Sekunden. Bei Sentry fällt sie von 133 auf 16 Sekunden. Der Editor startet statt in etwa 9,6 Sekunden nun in 1,2 Sekunden, und der Speicherbedarf halbiert sich ungefähr.

Zwei Details sind wichtiger als die reine Geschwindigkeit. Erstens: Es handelt sich um eine Portierung, nicht um ein von Grund auf neu geschriebenes Programm. Das Team hat die bestehende Typprüfungslogik nach Go übertragen und die Semantik beibehalten – 7.0 sollte daher dieselben Regeln durchsetzen, die Ihr Code bereits unter 6.0 besteht. Zweitens: Sie installieren es wie jedes andere Release, direkt aus dem typescript-Paket auf npm. Ein stabiles Release ist für etwa einen Monat später geplant, und Regressionen werden im Repository microsoft/typescript-go gemeldet, nicht im Haupt-TypeScript-Repository.

Was bringt einem Team also ein 10-mal schnellerer Compiler? Mehr als es auf den ersten Blick scheint.

Der Gewinn liegt nicht im Laptop, sondern in CI

Ein schnellerer Editor ist angenehm. Schnelleres CI verändert die Arbeitsweise. Wenn wir cloud-native Apps für Enterprise-Kunden mit PHP und Docker entwickeln, ist die Typprüfung meist eines der langsamsten Tore in der Pipeline – und sie liegt auf dem kritischen Pfad jedes einzelnen Merges. Einen zweiminütigen Check auf fünfzehn Sekunden zu verkürzen, spart nicht nur zwei Minuten. Es verändert das Verhalten. Entwickler hören auf, Änderungen zu bündeln, um der langsamen Pipeline auszuweichen. Reviewer bekommen ein grünes Häkchen, solange der Kontext noch frisch ist. Und die Gewohnheit „Ich merge und beobachte CI“, die leise den Main-Branch kaputt macht, verblasst.

Wir haben beobachtet, wie Teams ihre Architektur um langsame Werkzeuge herum bauten, ohne es zu merken: riesige Pull Requests, übersprungene lokale Checks, ein --no-verify-Reflex bei jedem Commit. Das meiste davon ist eine Reaktion auf Feedback, das zu lange auf sich warten lässt. Nimmt man die Wartezeit weg, verlieren viele dieser Gewohnheiten ihren Grund.

Ein schnellerer Compiler bleibt eine Abhängigkeitsänderung

Das ist der Teil, der in der Aufregung oft verloren geht. Den Compiler gegen ein Binary auszutauschen, das in einer anderen Sprache geschrieben ist, ist eine Supply-Chain-Entscheidung, kein kostenloser Gewinn. Bei unserer Pentesting- und Security-Review-Arbeit ist die Build-Toolchain einer der ersten Orte, die wir uns ansehen – denn sie läuft mit vollem Zugriff auf Ihren Quellcode und oft Ihre Secrets, auf jedem Entwicklerrechner und jedem CI-Runner. Ein neues tsc ist genau eine solche Komponente.

Das bedeutet nicht, dass der RC riskant zum Ausprobieren ist. Microsoft betreibt es seit über einem Jahr auf Codebasen mit mehreren Millionen Zeilen, innerhalb und außerhalb des Unternehmens. Es bedeutet, dass Sie es bewusst übernehmen sollten: Pinnen Sie die genaue Version, lesen Sie das Changelog, bevor Sie upgraden, und lassen Sie keinen einzelnen Entwickler den Compiler für das gesamte Team stillschweigend an einem Freitagabend austauschen.

Was Sie diese Woche tun sollten

Machen Sie 7.0 noch nicht zu Ihrem blockierenden CI-Check. Fügen Sie ihn neben dem bestehenden hinzu. Die meisten CI-Systeme erlauben es, einen zweiten Job auszuführen, der mit typescript@rc kompiliert und sein Ergebnis meldet, ohne den Merge zu blockieren. Lassen Sie beide einige Wochen laufen, vergleichen Sie die Fehler, und Sie wissen genau, wo 7.0 mit Ihrem aktuellen Build nicht übereinstimmt, bevor es wichtig wird. Da es sich um eine Portierung und nicht um ein Neuschreiben handelt, stellen die meisten Teams fest, dass der Diff leer ist – aber die wenigen, die auf einen Sonderfall stoßen, werden ihn lieber zu ihrem eigenen Zeitpunkt entdecken wollen, nicht während eines hastigen Upgrades nach dem Erscheinen des stabilen Releases.

Dieses Muster ist nicht TypeScript-spezifisch. Wir verwenden denselben Shadow-Ansatz in unserer Web- und Mobilarbeit, wann immer ein zentrales Werkzeug eine neue Hauptversion veröffentlicht. Ein Xcode- oder Android Gradle Plugin-Upgrade stufen wir in unseren nativen iOS- und Android-Projekten auf dieselbe Weise ein – in einem Paralleljob, lange bevor es die Rechner aller berührt. Die Teams, die sich verbrennen, sind meist jene, die „die Tests bestehen noch“ als Beweis lesen, dass sich nichts geändert hat. Wenn Sie einen Eindruck davon bekommen möchten, wie wir das in der Praxis umsetzen: Unsere Entwicklungsarbeit ist genau auf diese Art von stufenweisem, ruhigem Upgrade ausgerichtet.

Wenn Ihnen eine langsame Pipeline vertraut klingt, mit der Ihr Team stillschweigend gelernt hat umzugehen, sprechen Sie mit uns.