TypeScript 7.0 RC erschien am 18. Juni 2026 und ist der Release Candidate des Compilers, den Microsoft seit über einem Jahr nach Go portiert. Die Schlagzeile ist Geschwindigkeit: 7.0 ist oft rund 10-mal schneller als TypeScript 6.0, Resultat nativer Ausführung plus Shared-Memory-Parallelität statt des Single-Threaded-Compilers, der in JavaScript gebootet war und den das Ökosystem seit Beginn nutzt. Sie können ihn heute mit npm install -D typescript@rc installieren, und npx tsc --version meldet 7.0.1-rc.
Das ist das Ergebnis von Project Corsa, dem nativen Port, den Microsoft Anfang 2025 angekündigt hat. TypeScript 6.0 war bewusst als „Bridge-Release" angelegt, um den Sprung zu glätten, und das Team beschrieb 7.0 bereits im April als „extrem kurz vor der Fertigstellung". Der RC ist diese Fertigstellung, eingefroren im Funktionsumfang.
Portiert, nicht neu geschrieben
Das wichtigste Detail für alle, die ein Upgrade vorbereiten: 7.0 ist ein methodischer Port, keine Neu-Schreibung von Grund auf. Microsoft hat die bestehende TypeScript-Codebasis Datei für Datei nach Go verschoben, und die Typ-Prüf-Logik ist strukturell identisch mit 6.0. Der Compiler wurde gegen die über ein Jahrzehnt gewachsene Test-Suite evaluiert und läuft bereits in mehreren Codebasen mit mehreren Millionen Zeilen, innerhalb wie außerhalb von Microsoft, wobei Teams bei Bloomberg, Canva, Figma, Google, Linear, Notion, Slack, Vercel und VoidZero zu den Early Adopters zählen, die deutliche Build-Zeit-Reduktionen melden.
Praktisch: Jeder Code, der unter 6.0 sauber kompiliert, mit aktiviertem stableTypeOrdering und ohne gesetztes ignoreDeprecations-Flag, sollte unter 7.0 identisch kompilieren. Die Semantik hat sich nicht bewegt.
Eine Migration für den parallelen Betrieb
Weil die Go-Codebasis noch keine stabile programmierbare API freigibt (sie ist explizit auf TypeScript 7.1 in mehreren Monaten verschoben), hat Microsoft 7.0 so ausgelegt, dass es neben 6.0 ohne „welches tsc ist welches?"-Konflikte läuft. Veröffentlicht wurde @typescript/typescript6, ein Kompatibilitätspaket, das die 6.0-API re-exportiert und ein tsc6-Binary mitliefert.
Für Werkzeuge wie typescript-eslint, die über eine Peer-Dependency direkt aus typescript importieren, ist der empfohlene Weg über npm-Aliase. Pinnen Sie typescript auf den 6.0-Alias, damit diese Werkzeuge weiterlaufen, und fügen Sie einen zweiten Alias für 7.0 hinzu:
{
"devDependencies": {
"typescript": "npm:@typescript/typescript6@^6.0.0",
"typescript-7": "npm:typescript@rc"
}
}
Nun läuft npx tsc mit 7.0, während typescript-eslint weiterhin 6.0 unter dem Namen typescript verbraucht. Nightlies erscheinen weiterhin unter @typescript/native-preview (Binary tsgo); sobald 7.0 auf den latest-Tag wechselt, konvergieren alle Releases auf das Paket typescript.
Parallelität, die sich einstellen lässt
Der Geschwindigkeitsgewinn stammt aus der Parallelisierung von Parsen, Typ-Prüfen und Emit, und 7.0 legt die Hebel offen. --checkers setzt die Anzahl der Typ-Prüf-Worker, standardmäßig 4. Typ-Prüfen hat dateiübergreifende Abhängigkeiten, daher erzeugt 7.0 statt vollständig unabhängiger Worker einen festen Pool, der dieselben Eingabedateien stets identisch aufteilt und so deterministische Ergebnisse liefert, wenn auch mit etwas duplizierter Arbeit. Ein höherer Wert beschleunigt große Builds auf Mehrkernmaschinen, kostet aber Speicher; ein niedrigerer hilft beengten CI-Runnern.
--builders steuert parallele Project-Reference-Builder, was vor allem für Monorepos zählt. Beide Flags sind multiplikativ: --checkers 4 --builders 4 kann bis zu 16 Checker erzeugen, was Microsoft als möglicherweise übermäßig einstuft. --singleThreaded begrenzt den gesamten Compiler auf einen Thread für Debugging oder den Vergleich mit 6.0.
Auch der --watch-Modus wurde neu aufgebaut. Microsoft hat den File-Watcher des Parcel-Bundlers (@parcel/watcher) von C++ nach Go portiert, mit minimalen Assembler-Shims, um keine C++-Toolchain-Abhängigkeit einzuführen. Das Resultat sind laut Team deutliche Ressourcen-Verbesserungen im Watch-Modus über alle Plattformen hinweg, mit Dank an Devon Govett für den ursprünglichen Parcel-Watcher.
6.0s Defaults werden zum Fundament, und seine Deprecations werden zu harten Fehlern
7.0 übernimmt die neuen Defaults aus 6.0 und duldet nicht länger, was 6.0 als deprecated markiert hat. Die Defaults, die sich ändern: strict ist true, module ist esnext, target ist die aktuelle stabile ECMAScript-Version vor esnext, noUncheckedSideEffectImports ist true, libReplacement ist false, und stableTypeOrdering ist true und lässt sich nicht abschalten.
Die beiden Optionen, die Microsoft als „am überraschendsten" kennzeichnet, sind rootDir und types. rootDir ist nun standardmäßig ./, sodass Projekte, deren tsconfig.json außerhalb von src liegt, es explizit setzen müssen, um die Verzeichnisstruktur zu erhalten. types ist nun standardmäßig [], sodass globale Deklarationen aus @types-Paketen explizit aufgelistet werden müssen (das alte Verhalten lässt sich mit "types": ["*"] wiederherstellen).
Die als deprecated geltenden Optionen, die zu harten Fehlern werden, umfassen target: es5, downlevelIteration, moduleResolution: node/node10 (nutzen Sie nodenext oder bundler), module: amd/umd/systemjs/none, baseUrl, moduleResolution: classic sowie das Setzen von esModuleInterop oder allowSyntheticDefaultImports auf false. Das Schlüsselwort asserts auf Imports muss zu with werden, und /// <reference no-default-lib /> wird unter skipDefaultLibCheck nicht mehr respektiert. Die vollständige Liste steht in der CHANGES.md im Repo microsoft/typescript-go.
Zwei echte Änderungen auf Typebene
Zwei Änderungen betreffen das Verhalten auf Typebene statt die Konfiguration. Die Inferenz von Template-Literal-Typen erhält nun Unicode-Codepunkte: HeadTail<"😀abc"> ergibt ["😀", "abc"] statt das Emoji in zwei UTF-16-Surrogathälften zu zerlegen. Das richtet die Inferenz an der Semantik von for...of und Spread aus, bricht aber String-Utilities auf Typebene, die bewusst UTF-16-Codeeinheiten modellierten, etwa einige Length-Helfer.
Auch die Unterstützung von JavaScript (JSDoc) wurde überarbeitet, um konsistent mit der Analyse von .ts-Dateien zu sein. @enum, ein eigenständiger ?-Typ, @class als Konstruktor-Marker, das postfixe ! und die Closure-artige Funktionssyntax wie function(string): void werden nicht mehr speziell behandelt. Werte, die eingesetzt werden, wo Typen erwartet werden, benötigen nun typeof.
Die Editor-Erfahrung
Der Language-Service basiert auf dem Language Server Protocol und nutzt mehrere Threads, sodass der Editor dieselbe Parallelität gewinnt wie die Kommandozeile. Die VS-Code-Erweiterung TypeScript Native Preview ist der weg mit der geringsten Reibung zum Ausprobieren, und Microsoft hat die seit der Beta fehlenden Funktionen nachgeliefert: Auto-Imports, semantisches Highlighting, Inlay-Hints, Code-Linsen, Go-to-Source-Definition, verknüpftes Bearbeiten von JSX sowie das Sortieren und Entfernen ungenutzter Imports. Die internen Daten des Teams sprechen von über 20-mal weniger scheiternden Language-Server-Befehlen gegenüber 6.0.
Was jetzt tun und was beobachten
Der Upgrade-Pfad für die meisten Teams: Wechseln Sie, falls noch nicht geschehen, zuerst zu 6.0, räumen Sie dessen Deprecations aus, dann npm install -D typescript@rc und lassen Sie es in der CI laufen. Pinnen Sie --checkers, wenn Sie über Maschinen hinweg identische Ergebnisse wollen. Microsoft plant das stabile 7.0-Release für den kommenden Monat, wobei 7.1 die stabile programmierbare API bringt, die es den Werkzeugen erlaubt, 6.0 endgültig zu verlassen. Melden Sie Regressionen auf dem Issue-Tracker von microsoft/typescript-go, denn das RC-Fenster ist der Moment, in dem dieses Feedback am meisten zählt.
