Überprüfen versus Ausführen: Wo der Go-Compiler von TypeScript 7 in Ihre Toolchain passt

TypeScript 7 ersetzt den selbst gehosteten Compiler durch eine in Go geschriebene native Version, und die angegebenen Zahlen sind so hoch, dass Verwirrung darüber entsteht, was tatsächlich schneller wird. Ihre Produktions-JavaScript-Dateien ändern ihre Geschwindigkeit überhaupt nicht – Ihr Editor, Ihre CI-Typüberprüfung sowie die Builds Ihres Monorepos schon. Gleichzeitig haben Node, Bun und Vite den TypeScript-Compiler für das Ausführen und Umwandeln von Code optional gemacht. Diese Anleitung trennt diese Aspekte voneinander, damit Sie entscheiden können, was Sie aktualisieren sollten, worauf Sie warten müssen, und wie Sie eine Toolchain strukturieren können, in der Überprüfung und Ausführung zwei getrennte Aufgaben sind.

Durch die weite Verbreitung von TypeScript lohnt es sich, dies richtig umzusetzen. Im August 2025 berichtete GitHub, dass TypeScript zur am häufigsten genutzten Sprache bei monatlichen Beiträgen geworden sei und damit Python sowie JavaScript überholt habe – mehr als 2,6 Millionen Menschen tragen monatlich zum TypeScript-Code bei. Eine Veränderung in den Grundlagen dieses Ökosystems wirkt sich auf Frameworks, Linter, Paketmanager und Editor aus, wobei nicht alle im gleichen Tempo voranschreiten.

Von einem selbst gehosteten Compiler zu einem nativen

Vor Version 7 war tsc ein bootstrappiertes Programm. Seine Quelle war TypeScript, es wurde in JavaScript kompiliert, und dieses JavaScript lief unter Node, um die Projekte aller anderen zu analysieren, zu überprüfen und auszugeben. Die Selbsthosting-Lösung ist eine etablierte Praxis für Compiler, und dieses Design ermöglichte es der Sprache, ein Jahrzehnt des rasanten Wachstums zu durchlaufen. Seine Grenzen liegen jedoch im JavaScript-Runtime: ein einziger Hauptthread, ein für Garbage Collection vorgesehener Heap, der niemals für riesige In-Memory-Graphen aus Syntax-Node- und Typ-Daten optimiert wurde, sowie begrenzte Möglichkeiten, diese Daten zwischen verschiedenen Prozessen zu teilen.

Microsofts Lösung bestand aus einem Port, nicht aus einer Neuschreibung. Die Go-Codebasis spiegelt absichtlich die Struktur und das Verhalten der bestehenden Implementierung wider, sodass das Typensystem sowie seine Semantik unverändert bleiben sollen. Was sich ändert, ist die Grundlage dahinter: nativer Maschinencode, Threads, die Speicher teilen können, sowie deutlich mehr Möglichkeiten zum Parallelausführen von Aufgaben. Aus genau diesem Grund war Go die pragmatische Wahl; sein Speichermodell und der Garbage Collector ermöglichen es dem Team, den bestehenden Code mit ähnlichen Datenstrukturen zu übersetzen, anstatt alles um Regeln zur Eigentumsverwaltung herum neu zu entwerfen.

Die veröffentlichten Benchmarks zeigen, dass typische vollständige Builds 8- bis 12-mal schneller werden:

• Die VS Code-Codebasis benötigt von 125,7 Sekunden unter TypeScript 6 auf 10,6 Sekunden unter TypeScript 7.
• Der vollständige Build von Playwright verkürzt sich von 12,8 Sekunden auf 1,47 Sekunden.

Durch die Konfiguration von acht Type-Checker-Arbeitern sinken die Zeiten erneut auf 7,51 Sekunden (VS Code) und 1,16 Sekunden (Playwright).

„TypeScript ist zehnmal schneller“ ist eine genaue Zusammenfassung dieser Werte. Sie lässt sich jedoch leicht falsch interpretieren, da nicht klar ist, was zehnmal schneller ist.

Was wird schneller und was nicht

Nehmen wir einen kleinen, gewöhnlichen Codeabschnitt: eine Schnittstelle sowie ein Objekt, das dieser entspricht.

interface User {
  id: string;
  name: string;
}
const user: User = {
  id: '42',
  name: 'Arthur',
};

Egal welches Tool ihn kompiliert – der Browser oder Server erhält letztendlich reines JavaScript ohne die Typinformationen:

const user = {
  id: '42',
  name: 'Arthur',
};

Der Laufzeitumgebung ist nicht bekannt, welcher Compiler den Quellcode verarbeitet hat oder in welcher Sprache dieser Compiler implementiert ist. Sie sieht nur das erzeugte JavaScript, und diese Ausgabe bleibt unverändert wie zuvor. Daher ändert das Umschreiben von tsc in Go nichts an der Ausführungsgeschwindigkeit Ihrer Anwendung. Wenn eine Seite langsam ist oder ein API-Handler durch die CPU gebunden ist, wird TypeScript 7 daran nichts ändern.

Die Vorteile zeigen sich bereits früh in der Entwicklung, dort, wo TypeScript ständig läuft: beim Laden von Projekten, bei der Berechnung von Diagnosen, bei der Bereitstellung von Vervollständigungen und Funktionen zum Finden aller Referenzen, beim Überwachen von Dateien sowie bei der erneuten Überprüfung des Builds in CI. Eine Messung verdeutlicht dies gut: Das Öffnen einer Datei mit einem Fehler im VS Code-Repository dauerte früher etwa 17,5 Sekunden, bis die erste Diagnose angezeigt wurde; mit TypeScript 7 beträgt die Dauer weniger als 1,3 Sekunden. Der neue Sprachserver basiert auf dem Language Server Protocol, kann mehrere Threads nutzen, und Microsoft berichtet außerdem über deutlich weniger fehlgeschlagene Befehle des Sprachservers sowie Abstürze.

Die nützliche Sichtweise ist folgende: Die Anwendung selbst wird nicht schneller, doch die Arbeit mit der Anwendung schon. Bei einer großen Codebasis oder einem Monorepo verändert das Weglassen von Minuten pro Typüberprüfung sowie Sekunden pro Editor-Diagnose den Feedback-Zyklus, mit dem man den ganzen Tag zu tun hat. Das ist ein echter Produktivitätszuwachs – auch wenn kein Benutzer es jemals bemerken wird.

Weitere Neuerungen in TypeScript 7

Der native Compiler dominiert die Diskussion, doch mehrere Untersysteme wurden um ihn herum neu aufgebaut.

Parallelismus, den man anpassen kann

Die Analyse, die Erstellung von Ausgaben sowie Teile der Typüberprüfung können parallel ausgeführt werden, und bei Projektverweisen können mehrere Projekte gleichzeitig kompiliert werden – was insbesondere in Monorepos von Bedeutung ist. Man kann die Anzahl der Typüberprüfungsprozesse explizit erhöhen:

tsc --checkers 8

Oder deaktivieren Sie den Parallelismus ganz, bei Maschinen mit begrenzten Ressourcen oder wenn Sie während des Debuggens ein deterministisches Verhalten wünschen:

tsc --singleThreaded

Ein separates --builders-Flag steuert, wie viele Builds von Projektreferenzen gleichzeitig ausgeführt werden. Betrachten Sie diese eher als Einstellmöglichkeiten zur Optimierung und nicht als Schalter für „maximale Auslastung“. Jeder zusätzliche Worker benötigt seinen eigenen Speicherplatz für das Programm, wodurch ein CI-Runner mit vielen Kernen aber begrenzter RAM langsamer werden kann oder an Speichermangel leiden könnte, wenn Sie einfach Worker den Kernen zuordnen. Messen Sie auf Ihren tatsächlichen Runnern, bevor Sie eine Einstellung festlegen.

Eine neu konstruierte Überwachungsmodus-Version

--watch wurde ebenfalls neu implementiert. Das Team versuchte zunächst herkömmlichere plattformübergreifende Ansätze, die in Go verfügbar sind, doch das Abfragen des Dateisystems erwies sich für große Projekte als zu aufwendig. Schließlich wurden Ideen aus Parcel’s C++-Dateiüberwachung in Go übertragen, um eine neue Überwachungsfunktion zu entwickeln, die einen besseren Ressourceneinsatz auf verschiedenen Betriebssystemen ermöglicht.

Neue Standardwerte und entfernte veraltete Optionen

TypeScript 7 übernimmt die Konfigurationsänderungen, die während des Übergangs zu TypeScript 6 eingeführt wurden:

• strict ist standardmäßig aktiviert.
• Der Standardwert für module ist nun esnext.
• types beginnt als leere Array, sodass globale Typpakete nicht mehr automatisch erfasst werden.
• target: es5 wurde entfernt.
• Die klassische Modulauflösung wurde entfernt.

Die Ausgabe für AMD- und UMD-Module wurde entfernt.

baseUrl wird nicht mehr unterstützt.

Eine tsconfig.json, die seit der Zeit von Internet Explorer nicht mehr angepasst wurde, erfordert vermutlich Aufmerksamkeit. Insbesondere die Änderung bei types kann zu einer Flut von „Name nicht gefunden“-Fehlern für Testglobalen oder Node-Built-ins führen, solange man die abhängigen Pakete nicht auflistet. Falls Sie diese Standardeinstellungen noch nicht bearbeitet haben, behandelt unser praktischer Migrationsleitfaden zu den brisanten Standardeinstellungen von TypeScript 6.0 sie ausführlich, und die gleichen Lösungen gelten auch hier.

Das fehlende Element: eine stabile Compiler-API

Der wichtigste Aspekt ist etwas, was TypeScript 7.0 nicht bietet: eine stabile programmatische API. Für viele Projekte ist das wichtiger als jedes Flag oder Standardwert, denn es bestimmt, ob die Tools rund um den Compiler überhaupt funktionieren können.

Warum das Ökosystem nicht über Nacht wechseln kann

Den Compiler aus der Terminal zu aufrufen und ein Tool auf dessen Basis zu entwickeln, sind zwei völlig unterschiedliche Ansätze. Viele Frameworks, Sprachtools und Linter greifen nicht einfach auf das Binärdatei zu:

tsc

Sie laden TypeScript als Bibliothek und fordern von ihr Syntaxbäume, gelöste Typen, Antworten des Language-Service sowie weitere Compiler-Internas. Ein Ersatz für diese API ist in TypeScript 7.1 erwartet, und bis dahin unterstützt Microsoft offiziell den gleichzeitigen Einsatz beider Hauptversionen. Zum Zeitpunkt der Erstellung bedeutet das, dass viele Teams den nativen Compiler für Kommandozeilen-Prüfungen verwenden, während ihre Editor-Integrationen und Linter weiterhin die auf JavaScript basierende Version laden.

Mehrere bekannte Tools sind betroffen:

• Die Template-Typüberprüfung von Angular ist tief in TypeScript integriert, weshalb die vollständige Editor-Unterstützung von Angular vorerst weiterhin auf dem älteren Language-Service beruhen muss.
• Tools für Vue, Astro, Svelte, MDX und andere Formate, die TypeScript in einem anderen Dateityp einbetten, sind bis zum Erscheinen der neuen API mit ähnlichen Einschränkungen konfrontiert.

Nichts davon ist ein Mangel der Portierung. So sieht eine Migration eines grundlegenden Tools in einem echten Ökosystem aus: Der Motor ist bereits bereit, bevor alles, was daran angebracht wird, angepasst wurde.

Vier Möglichkeiten, wie ein Tool von TypeScript abhängen kann

typescript-eslint ist hierfür ein gutes Beispiel. ESLint selbst basiert nicht auf dem TypeScript-Compiler, daher wäre die Behauptung, „ESLint wurde schneller, weil TypeScript auf Go umgestellt wurde“, einfach falsch. typescript-eslint hingegen ist die Brücke, die es ESLint ermöglicht, TypeScript-Syntax zu analysieren und bei typbezogenen Regeln die Typinformationen von TypeScript abzufragen. Sein aktueller Parser stützt sich weiterhin auf die ältere Compiler-API, obwohl das Projekt bereits mit der nativen Implementierung experimentiert hat. Die Betreuer bereiten sich offensichtlich vor, doch die Einführung von TypeScript 7 bedeutet nicht einfach nur ein Anheben der Versionnummer.

Dieses Beispiel zeigt einen Unterschied, den man immer im Hinterkopf behalten sollte, wenn jemand sagt, ein Tool „verwendet TypeScript“. Es gibt mindestens vier verschiedene Beziehungen:

• In TypeScript geschrieben. Die Quelldatei des Tools selbst ist in TypeScript. Es profitiert davon, dass seine Wartungsteams schneller typüberprüfen und kompilieren können, doch die Nutzer bemerken keine Veränderung.
• Führt TypeScript aus. Laufzeitsysteme wie Node und Bun akzeptieren .ts-Dateien als Eingabe, ohne tsc einzusetzen.
• Transformiert TypeScript. Bundler und Transpiler entfernen Typen und überarbeiten die Syntax, jeweils für eine Datei.
• Hängt von den Semantiken von TypeScript ab. Linter mit typbewussten Regeln, Sprachdienste von Frameworks sowie Editor benötigen den Compiler, um ein ganzes Programm verstehen zu können.

Der native Port ändert sich je nach Kategorie unterschiedlich. Nur die letzte benötigt die Compiler-API, und es handelt sich genau um die Kategorie, die auf 7.1 warten muss.

Ein Paketmanager mitten in der Migration

pnpm zeigt, wie diese Kategorien miteinander interagieren. Es handelt sich um ein großes TypeScript-Monorepo mit vielen Paketen, umfangreichen CI-Verfahren sowie zahlreichen Editor-Analysen – was es auf dem Papier zu einem idealen Nutzer von TypeScript 7 macht. Letztendlich sollte es das auch werden. In der Zwischenzeit müssen seine Betreuer außerdem sicherstellen, dass typescript-eslint weiterhin funktioniert, und diese Integration mit dem Linter ist noch an die veraltete Compiler-Schnittstelle gebunden. Die Abhängigkeitskette sieht ungefähr so aus:

pnpm
  ↓
typescript-eslint
  ↓
TypeScript compiler API
  ↓
TypeScript 6 — for now

Auch ist es wichtig, klarzustellen, was die Nutzer von pnpm erwarten können. TypeScript 7 macht diesen Befehl nicht schneller:

pnpm install

Das Installieren von Paketen ist das Laufzeitverhalten von pnpm, und pnpm läuft als JavaScript unter Node – unabhängig davon, mit welchem Compiler seine Quelldateien überprüft wurden. Was TypeScript 7 verbessern kann, ist die Entwicklungsarbeit bei pnpm: Typüberprüfungen, CI-Ausführungen sowie andere durch Compiler gesteuerte Workflows. Doch selbst diese Verbesserung tritt nur so schnell ein wie der langsamste wichtige Knoten in seinem Abhängigkeitsgraphen. Ein großes Projekt kann keine grundlegenden Änderungen schneller umsetzen als die Tools, auf die es angewiesen ist.

Wo die Vorteile sofort spürbar sind

Projekte, die nur den Compiler als Befehlszeilen-Prüfer sowie einen Sprachserver benötigen, können sofort davon profitieren. VS Code ist das deutlichste Beispiel: Eine riesige TypeScript-Codebasis, in der Millionen von Entwicklern täglich die TypeScript-Entwicklungstools nutzen. Die Verkürzung der vollständigen Kompilierzeit von über zwei Minuten auf etwa zehn Sekunden ist bemerkenswert; die Verringerung der Wartezeit auf die erste Editor-Diagnose von etwa siebzehn Sekunden auf etwas über eine Sekunde ist etwas, das jeder spüren kann.

Playwright, eines der Benchmark-Projekte von Microsoft, verkürzt die Zeit für eine vollständige Kompilierung bei der Standardkonfiguration von 12,8 Sekunden auf 1,47 Sekunden. Das bedeutet wiederum nicht, dass Playwright Chromium schneller startet. Es bedeutet vielmehr, dass die Wartung und Überprüfung des eigenen Codes von Playwright viel schneller erfolgt. Angesichts der Tatsache, dass viele Entwicklertools selbst in TypeScript geschrieben sind, hat eine schnellere Wartung dieser Tools Auswirkungen auf den gesamten Ökosystem.

Vite behandelt bereits die Überprüfung und Transformation als getrennte Aufgaben

Vite ist hauptsächlich in TypeScript geschrieben, doch beim Bereitstellen oder Kompilieren der TypeScript-Anwendung ruft es den TypeScript-Compiler nicht auf, um jedes Modul zu transpilieren. Moderne Versionen von Vite nutzen einen speziellen Transformationspfad und überspringen bewusst die Typüberprüfung. In der Dokumentation wird empfohlen, TypeScript separat als einmalige Überprüfung auszuführen:

tsc --noEmit

oder kontinuierlich während der Entwicklung:

tsc --noEmit --watch

Die Argumentation ist schlüssig. Um eine Datei zu transformieren, reicht es aus, diese zu bearbeiten: Anmerkungen entfernen, einige Strukturen umschreiben und weitermachen. Die Typüberprüfung erfordert hingegen Kenntnisse des gesamten Modulgraphen, da eine Änderung in einer Datei einen Vertrag in einer anderen verletzen kann. Beides in derselben Schrittfolge durchzuführen zwingt die schnelle Operation, auf die langsame zu warten. Ein typisches Vite-Projekt weist daher zwei parallele Pfade vom selben Ausgangspunkt auf:

┌── Vite / Oxc ── transform ──> Browser
TypeScript source ──┤
                    └── TypeScript ───── type-check

Aus dieser Perspektive muss TypeScript 7 nicht der schnellste JavaScript-Transformer werden, denn Vite verfügt bereits über ein dafür optimiertes Tool. TypeScript kann sich auf die Aufgabe konzentrieren, das gesamte Programm zu verstehen – und diese Aufgabe ist nun erheblich schneller. Wenn Sie heute diese Konfiguration verwenden, hat das eine praktische Folge: Ein Typfehler stoppt den Entwicklungsserver nicht; stellen Sie sicher, dass tsc --noEmit in CI oder in einem Pre-Push-Hook ausgeführt wird, damit Fehler nicht durchdringen können.

JavaScript-Tools, die in allem außer JavaScript geschrieben sind

Hier gibt es einen breiteren Trend. Vites aktuelle Build-Pipeline verwendet Rolldown, und sowohl Rolldown als auch Oxc sind in Rust geschrieben. esbuild wählte bereits vor Jahren Go. Bun implementiert große Teile von sich selbst in Zig. Nun hat sich auch TypeScript mit Go zu ihnen gesellt.

Das ist keine Kritik an JavaScript. Die öffentlichen Schnittstellen erscheinen Entwicklern von JavaScript und TypeScript weiterhin natürlich, während die rechenintensiven Aufgaben wie Parsing, Auflösung und Analyse in Form von Native-Code ausgeführt werden. Verschiedene Schichten haben unterschiedliche Anforderungen, und TypeScript 7 ist das prominenteste jüngste Beispiel dafür, dass die Implementierungs Sprache pro Schicht gewählt wird.

Runtimes, die TypeScript ohne tsc ausführen

Auch auf der Runtime-Ebene findet eine ähnliche Trennung statt. Das traditionelle Denkmuster bei TypeScript-Projekten sah eine geradlinige Abfolge von Quellcode über Compiler zu JavaScript und schließlich zu Node vor:

TypeScript
    ↓
   tsc
    ↓
JavaScript
    ↓
  Node.js

Reale Projekte hatten stets mehr Schritte, doch die Grundidee blieb gleich: Node führte JavaScript aus, daher musste TypeScript zunächst in JavaScript umgewandelt werden. Heute funktioniert das direkt:

node server.ts

Der wichtige Punkt ist, dass Node den TypeScript-Compiler nicht ausführt. Die eingebaute Unterstützung ist absichtlich minimal: Es werden lösbare TypeScript-Syntaxteile entfernt und das Verbleibende ausgeführt. Es findet keine Typüberprüfung statt, und Syntaxe, die die Erstellung echten JavaScripts erfordern (anstatt lediglich die Anmerkungen zu entfernen), fallen außerhalb dieses Entfernungsschemas. Eine typisierte Deklaration wie diese:

const port: number = 3000;

wird vor der Ausführung faktisch in das Folgende umgewandelt:

const port = 3000;

"Erasable" ist das Schlüsselwort. Konstruktionen wie enum, namespace mit Laufzeitwerten oder Konstruktorparametereigenschaften erzeugen JavaScript, das im Quellcode nicht vorhanden war, weshalb reines Entfernen solcher Elemente nicht funktioniert. TypeScript bietet die Compileroption erasableSyntaxOnly, um solche Konstruktionen zu kennzeichnen, falls Sie möchten, dass Ihr Code weiterhin mit dem Typ-Entfernen kompatibel bleibt; prüfen Sie die aktuelle Dokumentation zu Node und TypeScript, um das genaue Verhalten in Ihren Versionen zu erfahren.

Diese Fähigkeit existiert bereits vor Node 26, daher sollte die direkte Ausführung von TypeScript nicht als Feature von Node 26 dargestellt werden. Node 26 bringt eigene Änderungen mit sich, darunter Temporal standardmäßig aktiviert, eine neuere V8-Version, ein weiteres bedeutendes Update für Undici sowie die üblichen Aufräumarbeiten nach einer großen Versionsentwicklung – doch das sind ein anderes Thema. Für diese Diskussion ist vielmehr die Richtung entscheidend: Node behandelt TypeScript zunehmend als Eingabe, die es direkt verarbeiten kann, anstatt erst tsc um die Erstellung von JavaScript zu bitten.

Bun behandelt TypeScript als normale Eingabe

Bun, das noch in der 1.x-Reihe ist, arbeitet bereits seit Anfang an auf diese Weise. Das Ausführen einer TypeScript-Datei erfolgt einfach so:

bun server.ts

Buns Loader entfernt und transformiert die TypeScript-Syntax vor der Ausführung mithilfe eigener Werkzeuge. Und erneut: Die Transpilation ist keine Typüberprüfung. Ein durchaus sinnvoller Bun-Arbeitsablauf besteht daher aus zwei Befehlen:

tsc --noEmit
bun server.ts

Die erste beantwortet die Frage „Erfüllt dieses Programm das Typsystem?“ Die zweite beantwortet „Kann dieses Programm ausgeführt werden?“ Moderne Node-Versionen unterstützen diese Trennung ebenfalls:

tsc --noEmit
node server.ts

In beiden Fällen wartet die Laufzeit niemals auf den Typprüfer, und der Typprüfer muss keine Ausgabe-Dateien erzeugen. Bedenken Sie, dass ein auf diese Weise ausgeführtes Projekt keinen Build-Schritt hat, um zufällig auftretende Typfehler aufzuspüren; wenn die Überprüfung nicht in das CI-System integriert ist, wird sie einfach nicht stattfinden.

Die Aufgabe von TypeScript besteht darin, Programme zu verstehen

Jahrelang war der Workflow auf ein einziges Pipeline-Verfahren beschränkt, bei dem der Compiler genau zwischen dem Schreiben und Ausführen des Codes lag:

Write TypeScript
      ↓
Compile TypeScript
      ↓
Run JavaScript

Moderne Entwicklungstools ähneln zunehmend zwei Zweigen aus derselben Quelle – einer für das Verstehen und Prüfen sowie eine andere für die Umwandlung und Ausführung:

┌── TypeScript ── understand and check
TypeScript source ────────┤
                          └── Runtime / bundler ── transform and execute

Vite kann Oxc nutzen, um Code zu transformieren, während tsc ihn überprüft. Node entfernt selbstständig die lösbaren Syntaxelemente. Bun verfügt über seinen eigenen Loader. Keines dieser Tools benötigt TypeScript 7 oder irgendein tsc, um Ihre Anwendung auszuführen. Genau deshalb bleibt der native Compiler weiterhin wichtig: Die wichtigste Aufgabe von TypeScript besteht nicht mehr darin, eine .ts-Datei schnell in eine .js-Datei umzuwandeln – etwas, was andere Tools bereits gut bewältigen. Sein wahrer Wert liegt in Fragen bezüglich des gesamten Programms, wie zum Beispiel:

• Ist dieser Wert mit dem Vertrag kompatibel, in den er übergeben wird?
• Hat eine Refaktorierung einen Verbraucher in einem anderen Paket beschädigt?
• Ist diese generische Einschränkung korrekt?
• Auf was bezieht sich dieses Symbol, und wo wird dieser Typ sonst noch verwendet?
• Was sollte der Editor hier als Vervollständigung anbieten?

Um diesen Anforderungen gerecht zu werden, ist weitaus mehr Kontext erforderlich als nur das Löschen von : string aus einer Zeile – und genau diese Analyse des gesamten Programms ist der Punkt, bei dem die Go-Portierung eine dramatische Beschleunigung bewirkt. Für einen tieferen Einblick in die nativ über diese Tools ausgeführte TypeScript-Programme finden Sie unseren Migrationsleitfaden zum TypeScript-Go-Kompilator und zur nativen Ausführung.

Haupterkenntnisse

• TypeScript 7 ist eine Portierung des bestehenden Kompilators auf Go, keine Neugestaltung der Sprache; das erzeugte JavaScript sowie die Laufzeitleistung Ihrer Anwendung bleiben unverändert.
• Die Vorteile zeigen sich während der Entwicklung: Vollständige Builds sind in der Regel 8- bis 12-mal schneller, die Diagnosen im Editor erfolgen deutlich rascher, und der Language Server ist stabiler.

Stellen Sie --checkers, --builders und --singleThreaded auf die tatsächlichen Speichergrenzen im CI ein, anstatt blind so viele Worker wie möglich zu nutzen.

Rechnen Sie mit einer Übergangsphase. Da es bis zur Version 7.1 keine stabile Compiler-API gibt, könnten Angular, Vue, Svelte, Astro, MDX-Tools sowie typescript-eslint dazu führen, dass Sie für bestimmte Integrationen weiterhin TypeScript 6 verwenden müssen; der parallele Betrieb beider Versionen wird unterstützt.

Überprüfen Sie tsconfig.json auf die neuen Standardwerte sowie entfernte Optionen (strict, module, types, ES5-Zielversion, klassische Auflösung, AMD/UMD, baseUrl).

Betrachten Sie die Typüberprüfung als eigenständigen Schritt. Vite, Node und Bun führen oder transformieren TypeScript, ohne es zu überprüfen; machen Sie daher tsc --noEmit zu einem obligatorischen Bestandteil des CI-Prozesses.