TypeScript 7 und die Go-Portierung: Schnellere Kompilierungen, Verbesserungen im Speichermanagement und Feedback im Editor.

Jeder, der bereits seit Jahren TypeScript verwendet, kennt diesen Rhythmus. Zuerst wird Code geschrieben, der Editor analysiert ihn eine Weile, TypeScript verarbeitet das Projekt, anschließend wird tsc ausgeführt – und es muss wieder gewartet werden. In einem großen Monorepo ist diese Pause lang genug, um Kaffee zu holen. Das bedeutet jedoch nicht, dass das Tool schlecht konzipiert ist. Sein Typsystem sowie die Sprachwerkzeuge haben sich stark genug entwickelt, um sehr große Codebasen zu bewältigen – und genau deshalb ist es so zentral für die JavaScript-Welt geworden. Doch diese Stärke hatte ihren Preis: Mit der Erweiterung der Projekte wurden der Compiler und der Language Server zu Leistungsengpässen.

TypeScript 7.0 ist Microsofts Antwort darauf, und das Bemerkenswerte ist, dass sich die Hauptveränderung nicht in einem neuen Operator, Schlüsselwort oder Syntaxtrick zeigt. Es handelt sich vielmehr um den zugrunde liegenden Compiler. Der TypeScript-Compiler wurde früher in TypeScript selbst geschrieben – eine angenehm rekursive Struktur, die gut funktionierte, allerdings bedeutete dies, dass der Compiler innerhalb des Laufzeitmodells von JavaScript laufen musste. Für Version 7 portierte Microsoft den Compiler auf Go, wodurch eine native Implementierung entstand, die darauf ausgelegt ist, moderne Hardware sowie Parallelisierung zu nutzen.

Das ist das Wichtigste, was man über diese Version verstehen muss: TypeScript 7 ist in erster Linie kein neues Programmiersprache, sondern ein neuer Compiler für die Sprache, die die Nutzer bereits verwenden. Diese Sichtweise erklärt fast alles Weitere darüber.

Die Geschwindigkeitswerte

Die Hauptzahl zeigt eine Zehnfachbeschleunigung. Microsofts Benchmarks zeigen, dass vollständige Builds in der Regel 8 bis 12 Mal schneller laufen, je nach Projekt, und diese stammen aus großen, realen Codebasen und nicht aus synthetischen Mikrobenchmarks.

Die Kompilierzeit ist sogar nicht das auffälligste Ergebnis, denn auch der Language Server wird schneller. Im Beispiel von Microsoft mit der VS Code-Codebasis ging das Öffnen einer Datei, die einen Fehler enthielt, von etwa 17,5 Sekunden vor dem Auftreten des ersten Fehlers auf weniger als 1,3 Sekunden zurück. Das bedeutet eine völlig andere Arbeitsweise, und in großen Repositorien ist das wichtiger als das Weglassen einiger hundert Millisekunden bei einer Produktionskompilierung.

Jeder Kern wird genutzt

Moderne Maschinen verfügen über viele Kerne, während tsc ursprünglich nur über einen verfügte. TypeScript 7 nutzt diese Kerne weitaus effektiver: Die Analyse, die Typüberprüfung sowie die Erstellung der Ausgabe können dort, wo möglich, parallel ausgeführt werden. Zudem werden einige experimentelle Schalter hinzugefügt:

--checkers
--builders
--singleThreaded

Die ersten beiden bieten eine genauere Kontrolle darüber, wie die parallele Arbeit aufgeteilt wird, und --singleThreaded deaktiviert den Parallelismus bei Bedarf, beispielsweise beim Debuggen des Compilerverhaltens oder im Betrieb in einem begrenzten Umfeld.

Monorepos können am meisten davon profitieren. Stellen Sie sich ein Repository mit einem Apps-Verzeichnis vor:

apps/
  web/
  admin/
  mobile/

und ein Paketverzeichnis:

packages/
  ui/
  api/
  config/
  utils/
  domain/

TypeScript wurde früher dazu verwendet, eine enorme Menge an sequenziellen Aufgaben innerhalb dieses Abhängigkeitsgraphen auszuführen. Mit Version 7 können nun mehr dieser Aufgaben gleichzeitig abgewickelt werden. Es geht also nicht nur darum, dass der Compiler schneller ist, sondern auch darum, dass der Compiler endlich die Hardware nutzen kann, auf der er läuft.

Arbeitsspeicher

Leistung bedeutet nicht nur CPU-Zeit. Große TypeScript-Projekte können mehrere Gigabyte RAM verbrauchen, insbesondere wenn der Language Server neben einem Editor, einem Browser, Docker und Dev-Servern läuft. Die von Microsoft veröffentlichten Benchmarks zeigen, dass der Arbeitsspeicherverbrauch bei mehreren großen Projekten um etwa 6 % bis 26 % sinkt:

• Bluesky: etwa 26 % weniger
• VS Code: etwa 18 % weniger
• tldraw: etwa 15 % weniger
• Playwright: etwa 11 % weniger

Neben zehnmal schnelleren Kompiliervorgängen mag das nach wenig klingen, doch jeder, der schon einmal gesehen hat, wie der Arbeitsspeicher eines Laptops in einem großen Monorepo verschwindet, versteht den Wert davon.

Ein neuer Sprachserver

Der größte Reiz von TypeScript rührte ohnehin nie von tsc her. Er kommt vom Editor: Vervollständigungen, Anzeige von Typinformationen beim Überfahren mit der Maus, Sprung zu einer Definition, Auflistung aller Verweise, Umbenennung eines Symbols überall, inline-Anzeige von Fehlern sowie ein-Klick-Lösungen. Ein großer Teil dessen, was als moderne JavaScript-Entwicklung wahrgenommen wird, beruht darauf.

TypeScript 7 bringt einen neuen Sprachserver mit, der auf dem Language Server Protocol basiert und die native Implementierung sowie Multithreading nutzt. Das Team erweitert kontinuierlich seine Funktionalitäten: Code-Linsen, eingebettete Hinweise, semantische Hervorhebung, Sortierung von Importen sowie Entfernung ungenutzter Importe sind bereits verfügbar, ebenso wie automatische Imports, Funktion „Zur Quelldefinition“ sowie assoziiertes Bearbeiten von JSX und Vervollständigungen für Tags. Das Ziel geht über eine schnellere tsc-Ausführung hinaus: Der gesamte Prozess vom Eingeben bis zur Rückmeldung wird schneller – und das ist wohl der größere Vorteil.

Deterministische Ausgabe unter Parallelität

Eine Veränderung ist weniger spektakulär, aber technisch interessant. TypeScript führt viele interne Buchhaltungsprozesse mit Typen, Symbolen, Unionen und Deklarationen durch. Wenn mehrere Worker gleichzeitig ausgeführt werden, kann die Reihenfolge, in der interne Objekte erstellt werden, variieren, was zu unterschiedlichen internen IDs führen und somit die Reihenfolge der generierten Deklarationen verändern könnte.

TypeScript 7 bewältigt dies, indem es die Elemente aus dem Inhalt der internen Objekte deterministisch ordnet, anstatt von der Reihenfolge abhängig zu sein, in der sie zufällig aufgetroffen werden. Nehmen wir diese Funktion:

function foo(condition: boolean) {
  return condition ? 100 : 500;
}

Es kann eine Aussage wie diese liefern:

export declare function foo(
  condition: boolean
): 100 | 500;

Und die Reihenfolge der Union bleibt unverändert, egal wie die parallelen Aufgaben ablaufen. Die meisten Entwickler werden es nicht bemerken, aber genau diese Ingenieursarbeit sorgt dafür, dass ein hochparalleler Compiler zuverlässig ist.

Keine Feature-Version

Jeder, der etwas Ähnliches erwartet:

type NewSuperPower<T> = ...

Oder eine große Anzahl neuer Sprachfunktionen könnte TypeScript 7 auf den ersten Blick enttäuschend finden. Der größte Teil der Anstrengungen galt der Infrastruktur statt neuen Möglichkeiten des Typensystems. Das Team hat jahrelang die Grundlagen für die nächste Generation von TypeScript gelegt, und nun existiert sie. Der Roadmap weist nach der Version 7.0 wieder auf die Entwicklung neuer Funktionen, bessere Benutzerfreundlichkeit, weitere Leistungssteigerungen sowie eine neue Compiler-API hin. Die Veröffentlichung liest sich eher wie der Beginn einer neuen Ära denn als das Ende der vorherigen.

Hinweise für Entwickler von Tools

Hier wird es für diejenigen, die Tools entwickeln, interessant. TypeScript 7.0 kommt ohne die alte Compiler-API, und das Team erwartet, dass 7.1 eine neue einführt. Das ist von großer Bedeutung, denn ein großer Teil des Ökosystems nutzt nicht nur tsc. Linter, Framework-Compiler, Sprachdienste und Build-Tools kommunizieren programmgesteuert mit TypeScript.

Das ist ein Grund, warum TypeScript 6 und 7 vorerst nebeneinander existieren müssen. Microsoft führte @typescript/typescript6 ein, um den Übergang zu erleichtern – so kann ein Projekt die Version 6 weiterhin für Tools nutzen, die ihre API noch benötigen, während gleichzeitig der Compiler der Version 7 separat verwendet wird. Ein Compiler-Upgrade ist nicht immer so einfach wie das Ändern einer einzigen Zeile:

{
  "devDependencies": {
    "typescript": "^7.0.0"
  }
}

In großen Ökosystemen ist der Compiler eine Infrastruktur, und Infrastrukturen weisen Abhängigkeiten auf.

Eine weitere Beschränkung betrifft Frameworks und Tools, die TypeScript in ihre eigenen Kompilier- oder Language-Service-Pipelines integrieren. Das Team bezeichnet Vue, MDX, Astro, Svelte und Angular als Bereiche, in denen die Unterstützung für das neue Language-Service-Design noch nachhinkt – wieder einmal erklärt die fehlende stabile programmatische API den Grund dafür. Eine einfache React- und TypeScript-Anwendung kann ohne große Probleme migriert werden. Eine komplexe Integration in ein Framework, ein Compiler-Plugin oder ein Language-Service-Plugin birgt hingegen größere Herausforderungen. Es lohnt sich, dies vor dem Aufrüsten eines großen Produktionsrepositoriums zu überprüfen.

TypeScript 6 als Sprungbrett

TypeScript 6 war niemals nur die Version, die auf 7 folgte. Es wurde absichtlich als Brückenversion entwickelt. Mehrere alte Compileroptionen wurden dort als veraltet gekennzeichnet und in 7 vollständig entfernt, weshalb das Team empfiehlt, sie vor dem Sprung auf die neue Version zu beseitigen. Das Durchlaufen der Zwischenversion, wie unten gezeigt, ist besser als die Behandlung von 7 als eigenständiger Upgrade-Schritt:

TypeScript 5.x
      ↓
TypeScript 6
      ↓
TypeScript 7

Jede Außergebrauchsetzungswarnung, die ein Projekt unter TypeScript 6 erzeugt, verdient Aufmerksamkeit. Es handelt sich dabei im Grunde um Migrationshinweise aus der Zukunft.

Warum der Feedback-Zyklus wichtig ist

TypeScript verschwindet nach der Kompilierung, weshalb Frontend-Entwickler es selten als Teil der Laufzeit der Anwendung betrachten. Dennoch prägt es stark die Entwicklungslaufzeit. Immer dann, wenn ein Editor einen solchen Zyklus durchläuft:

type something
↓
autocomplete appears
↓
you navigate to a definition
↓
you rename a symbol
↓
you save
↓
CI runs
↓
the project gets type-checked

TypeScript ist jedes Mal beteiligt, und seine Rolle wächst mit den Anwendungen. Eine Verzögerung von 100 Millisekunden spielt keine Rolle, eine von 10 Sekunden schon, ein Warten von 30 Sekunden verändert die Arbeitsweise einer Person, und eine fünfminütige Typüberprüfung im CI-Prozess beeinflusst die Arbeitsweise eines ganzen Teams. Die wichtigste Eigenschaft von TypeScript 7 ist daher nicht eine zehnmal schnellere Kompilierung, sondern eine kürzere Zeitspanne zwischen dem Schreiben von Code und dem Erkennen, ob er richtig ist.

Outprobieren

Bei einem neuen Projekt lohnt es sich eindeutig, TypeScript 7 zu prüfen. Bei einem bestehenden Projekt ist ein vorsichtigerer Ansatz angebracht. Beginnen Sie damit, es als Entwicklungskomponente zu installieren:

npm install -D typescript@7

Dann führen Sie eine Typüberprüfung durch, ohne etwas auszugeben:

npx tsc --noEmit

und prüfen Sie die Ergebnisse, indem Sie diese Bereiche durchgehen:

1. Kompilierfehler
2. Veraltete Konfiguration
3. Kompatibilität der Build-Tools
4. Integration von ESLint
5. Integration des Frameworks
6. Verhalten der IDE
7. Leistung im CI
8. Arbeitsspeicherverbrauch

In einem großen Monorepo sollten Sie vor und nach den Änderungen Benchmarks durchführen, unter Verwendung von Tools wie:

time npx tsc --build

Und vergleichen Sie die Ergebnisse mit der aktuellen TypeScript-Version. Die endgültige Zahl sollte nicht der einzige Fokus sein – vielmehr zählt die gesamte Entwicklererfahrung.

Die Grundlagen neu aufbauen

TypeScript 7 zeichnet sich in den Frontend-Tools dadurch aus, dass das Team auf die übliche Vorgehensweise verzichtete, weiteren Funktionen zur bestehenden Architektur hinzuzufügen, und stattdessen die Basis neu konstruierte. Die Sprache selbst benötigte keine Neugestaltung – die Infrastruktur hingegen schon. Der Zeitpunkt ist ebenfalls sinnvoll: Mit größeren JavaScript-Projekten, verbreiteten Monorepos, überall vorhandenen typsicheren APIs, intelligenteren Editoren, KI-basierten Programmierwerkzeugen, die nach semantischen Daten dürsten, sowie Entwicklern, die nahezu sofortige Antworten erwarten. Ein Compiler, der für eine Anwendung aus dem Jahr 2015 ausreicht, hält nicht unbedingt mit einem Monorepo aus dem Jahr 2026 Schritt.

Einfach ausgedrückt gibt die neue Version zu, dass das alte Design funktionierte, aber moderne Software es überholt hat. Anstatt das bereits von den Entwicklern beliebte Typsystem wegzulassen, baute das Team das darunterliegende System neu auf. Aus diesem Grund ist diese Version bedeutender, als es ihre sichtbare Funktionsliste vermuten lässt. Sie bildet die Grundlage für die zukünftige Entwicklung von TypeScript sowie für einen schnelleren tsc. Wenn die versprochenen Vorteile sich auf das gesamte Ökosystem auswirken, könnten die spannendsten neuen Funktionen von TypeScript sogar nicht bereits in Version 7 enthalten sein. Vielmehr könnten sie erst dann praktikabel werden, weil Version 7 schnell genug ist, um sie zu entwickeln.

„Zehnmal schneller“ ist die Schlagzeile. Hinter diesem Slogan stecken Parallelisierung, native Ausführung, reduzierter Speicherverbrauch, ein neuer Sprachserver, deterministische Compilerausgaben sowie Grundlagen für zukünftige Tools. Für alle, die große TypeScript-Anwendungen warten, ist das wohl wertvoller als wieder nur ein weiteres Typ-Hilfsmittel.