TypeScript 7 vs. TypeScript 6: Was sich ändert, was kaputtgeht und wie das Upgrade gelingt

Über ein Jahrzehnt lang war tsc ein JavaScript-Programm, das JavaScript-Programme prüft, und jedes Team mit einem großen Monorepo kennt die Grenzen: ein Check von 30 Sekunden, ein Editor, der eine Minute zum Aufwachen braucht, ein CI-Job, der 8 GB Heap reserviert. TypeScript 7 ersetzt diese Engine. Compiler und Language Service sind jetzt ein natives Programm in Go, die Sprache bleibt unverändert, und npm i -D typescript installiert es.

„Dieselbe Sprache, nur schneller” ist das Versprechen, und es stimmt größtenteils. Das „größtenteils” ist der interessante Teil. Dieser Leitfaden vergleicht TypeScript 7 und TypeScript 6 direkt, zeigt einen Benchmark mit echten Open-Source-Projekten, darunter einen Fall, in dem beide Compiler nicht übereinstimmen, listet jede Option, die zum harten Fehler wurde, und beschreibt einen Upgrade-Weg, der dein Build nicht an einem Freitag zerlegt.

TypeScript 7 vs. 6 auf einen Blick

	TypeScript 6.0	TypeScript 7.0
Veröffentlicht	23. März 2026 (6.0.3 am 16. April)	8. Juli 2026 (Beta 21. April, RC 18. Juni)
Geschrieben in	TypeScript/JavaScript, läuft auf Node.js	Go, natives Binary
Rolle	Letztes Release auf der JS-Codebasis, die Brücke von 5.9	Der neue Standard-Compiler und Language Service
Parallelität	Ein Thread	Paralleles Parsen, Prüfen und Emittieren (--checkers, --builders)
Veraltete Optionen	Warnung; ignoreDeprecations: "6.0" unterdrückt sie	Harte Fehler
Compiler-API	Ja (import ts from "typescript")	Nicht in 7.0; neue API in 7.1
Language Services für Vue, Svelte, Astro, MDX, Angular	Funktionieren	Noch nicht
Installation	typescript@6 oder @typescript/typescript6 (tsc6)	typescript@latest (zum Zeitpunkt des Schreibens 7.0.2)

Die Namen sorgen für den Großteil der Verwirrung, deshalb genau: TypeScript 6.0 ist nicht „die langsame Version”. Es ist das Release, das den Boden bereitet hat: Es hat Standardwerte geändert, die Altoptionen als veraltet markiert und ein Flag für deterministische Diagnosen ergänzt, damit 7.0 ein geradliniger Port sein konnte. Die ausführlichen Ankündigungen stehen im Blog des TypeScript-Teams für 6.0 und 7.0.

Warum 7 schneller ist: nativer Code und parallele Worker

Ein TypeScript-Build hat vier Stufen: Dateien parsen , Namen an Symbole binden , Typen prüfen und Ausgabe emittieren. In TypeScript 6 läuft alles in einem JavaScript-Thread unter dem Speicherlimit des V8-Heaps. Das Prüfen ist der teure Teil, und zugleich der, der sich am schwersten aufteilen ließ.

TypeScript 7 ändert zwei Dinge gleichzeitig. Der Code ist nativ: kein JIT-Warmup und kein garbage-collecteter Heap aus JavaScript-Objekten. Und die Stufen teilen sich den Speicher, sodass die Arbeit auf Threads verteilt werden kann:

Die Geschwindigkeit kommt aus nativem Code plus Parallelität. Beides lässt sich einstellen, und beides kostet Speicher, wenn man aufdreht.

Drei Flags steuern die Parallelität (die Release-Notes führen --checkers und --builders als experimentell):

• --checkers N legt die Zahl der Type-Checking-Worker fest (Standard 4). Mehr Worker brauchen mehr Kerne und mehr Speicher, weil jeder seine eigene Sicht auf das Programm hat.
• --builders N baut Projekt-Referenzen parallel, unter tsc --build. Es multipliziert sich mit --checkers: 4 Builder mit 4 Checkern können 16 Worker bedeuten.
• --singleThreaded schaltet alles ab, nützlich auf kleinen CI-Runnern und für den Benchmark unten.

Wenn dich interessiert, wie eine native Laufzeit solche Arbeit auf OS-Threads verteilt: Die Go-Seite davon behandelt Wie viele Threads nutzt Go wirklich?.

Der Watch-Modus wurde auf einem nativen File-Watcher neu gebaut, und der Language Service hat dieselbe Behandlung bekommen. Die von Microsoft gemeldeten Zahlen aus dem Release-Post sind gut zu kennen, mit dem Vorbehalt, dass sie von Microsoft und von großen Codebasen stammen: „typischerweise 8- bis 12-mal” bei Full Builds, die Zeit bis zum ersten Fehler in VS Code von 17,5 s auf unter 1,3 s, Slacks CI-Type-Check von 7,5 auf 1,25 Minuten, und bei Canva die Zeit bis zum ersten Fehler im Editor von 58 auf 4,8 Sekunden.

Der Benchmark: drei echte Projekte, drei Compiler

In den Release-Notes steht „10-mal schneller”. Ich wollte das an Code sehen, den ich nicht selbst geschrieben habe, also habe ich drei beliebte Open-Source-Projekte genommen, jedes mit TypeScript 6.0.3, TypeScript 7.0.2 (Standard und --singleThreaded) und der 7.1.0-Beta vom 20. Oktober geprüft und jeden Lauf gestoppt. Der gesamte Aufbau ist Open Source, du kannst ihn also auf deiner eigenen Maschine wiederholen: typescript-7-vs-6-benchmark auf GitHub. Jeder Lauf war tsc -p <tsconfig> --noEmit: nur Type-Checking, ohne Emit.

Die Testkandidaten, zuerst der Stresstest:

• type-fest , eine Sammlung von Typ-Utilities, die fast ihre gesamte Zeit mit Typ-Berechnung verbringt. Rekursive bedingte Typen bis zum Anschlag.
• kysely , ein typsicherer SQL-Query-Builder. Eine typische Bibliothek mit vielen Generics.
• hono , ein Web-Framework, zweimal geprüft: nur der Quellcode und Quellcode plus Tests. Bei den Tests beginnen die beiden Compiler, sich zu widersprechen, wie du unten siehst.

Jede Konfiguration lief mehrfach in getrennten Prozessen mit Node.js 24. Der erste Lauf wurde als Warm-up verworfen, die Tabelle zeigt den Median der übrigen. Alle Compiler bekamen denselben großzügigen Node-Heap. Die 7.1-Beta hatte bei type-fest ein paar Dateien mehr im Programm, lies ihre Spalte also als nahen, nicht als exakten Vergleich.

Projekt	TS 6.0.3	TS 7.0.2 --singleThreaded	TS 7.0.2 Standard	TS 7.1.0-beta	Speedup 7.0.2 vs. 6.0.3
type-fest	23,9 s	16,4 s	8,1 s	4,6 s	2,9×
kysely	1,37 s	0,48 s	0,27 s	0,22 s	5,1×
hono (Quellcode + Tests)	0,82 s	0,34 s	0,16 s	0,15 s	5,0×
hono (nur Quellcode)	0,46 s	0,17 s	0,10 s	0,10 s	4,4×

Der native Code allein bringt das 1,5- bis 2,9-Fache. Vier parallele Checker legen noch einmal das 1,6- bis 2,1-Fache obendrauf.

Was die Zahlen sagen, ohne sie schönzurechnen:

• 3- bis 5-mal, nicht 10-mal. Das liegt unter den 8–12 aus der Ankündigung, und ich würde die Tabelle nicht passend biegen. Microsofts Zahlen gelten für Full Builds großer Repositories, die Projekte hier sind kleiner. type-fest ist der Extremfall: ein Haufen rekursiver bedingter Typen, die Zeit geht fast nur in die Typ-Berechnung, und trotzdem war es fast dreimal so schnell. Eine faire Zusammenfassung lautet „je nach Codebasis grob 3- bis 12-mal”, und verlässlich einordnen kannst du deine nur durch Messen.
• Der native Code allein ist die größere Hälfte. --singleThreaded war 1,5- bis 2,9-mal schneller als TypeScript 6. Die vier Standard-Checker halbierten die Zeit dann ungefähr noch einmal (1,6- bis 2,1-mal).
• TypeScript 6 kommt mit dem Standard-Node-Heap bei type-fest gar nicht durch. Es lief bei etwa 4 GB Heap voll und brauchte ein erhöhtes --max-old-space-size, die JavaScript-Obergrenze, die ein natives Binary nicht hat.
• 7.1 ist noch einmal schneller. Die Beta senkte type-fest von 8,1 s auf 4,6 s, also 5,1-mal schneller als 6.0.3, und war bei den anderen 4,7- bis 6,4-mal schneller als TypeScript 6.

Beim Speicher ist das Bild gemischter. Maximaler Resident Memory in Megabyte:

Projekt	TS 6.0.3	TS 7.0.2 Standard	TS 7.1.0-beta
type-fest	6.196	7.141	5.838
kysely	460	307	222
hono (Quellcode + Tests)	440	207	165
hono (nur Quellcode)	327	117	97

Bei den kleinen und mittleren Projekten brauchte TypeScript 7 ein Drittel bis zwei Drittel weniger Speicher. Bei type-fest, mit der meisten Typ-Arbeit, brauchten vier Checker etwa 15 % mehr als der einzelne JavaScript-Thread, und die 7.1-Beta weniger als beide. Wenn deine CI-Runner speicherbegrenzt sind, ist --checkers 2 oder --singleThreaded der erste Regler zum Ausprobieren.

Achtung

Schnell heißt nicht identische Ergebnisse. Bei hono’s Testsuite meldete tsc 6.0.3 0 Fehler und tsc 7.0.2 4: zwei ungenutzte @ts-expect-error-Direktiven (TS2578) und zwei „No overload matches this call”-Fehler (TS2769, string nicht zuweisbar an string[]), alle in einer Testdatei. Die 7.1-Beta meldete 6, und bei hono’s reiner Quellcode-Konfiguration kamen mit der Beta 2 noImplicitAny-Fehler hinzu, die 6.0 und 7.0 nicht meldeten. Jeder davon kann eine berechtigte Korrektur oder eine Regression sein, und in beiden Fällen willst du es in einem Branch herausfinden, nicht im Release.

Hinweis

Nachstellen in drei Befehlen: git clone https://github.com/LF3551/typescript-7-vs-6-benchmark, dann npm run setup und npm run bench. Das Repository pinnt die drei Projekte an exakten Commits, installiert TypeScript 6.0.3, 7.0.2 und 7.1.0-beta in getrennten Ordnern, damit die Binaries sich nicht vermischen, und nutzt für alle Compiler dasselbe NODE_OPTIONS=--max-old-space-size. Eigene Projekte trägst du in config.json ein. Zahlen von einer einzelnen Maschine sind ein Plausibilitätscheck, keine Bestenliste; vergleiche Verhältnisse, nicht Sekunden.

Was TypeScript 6 für dich geändert hat

Der Großteil der Upgrade-Arbeit passiert in 6.0, denn dort haben sich die Standardwerte verschoben. Wenn deine tsconfig.json kurz ist und sich auf Defaults verlässt, sind das die, die beißen:

Einstellung	Standard vor 6.0	Standard in 6.0 und 7.0
strict	false	true
module	commonjs	esnext
target	es5	die neueste stabile ECMAScript-Version
types	alle @types/*	[] (nichts wird automatisch eingebunden)
rootDir	aus den Eingabedateien abgeleitet	der Ordner mit der tsconfig.json
noUncheckedSideEffectImports	false	true
libReplacement	true	false
Typ-Reihenfolge (stableTypeOrdering)	nicht deterministisch	in 6.0 optionales Flag, in 7.0 immer an

Zwei davon verdienen Aufmerksamkeit. types: [] heißt: process, describe und jedes andere globale Symbol aus @types/node oder @types/jest verschwindet, bis du es auflistest, der häufigste erste Fehler in einem hochgezogenen Projekt. Der Vorteil ist real: Die 6.0-Ankündigung nennt, dass viele Projekte 20–50 % Build-Zeit gewannen, nur weil sie types explizit setzten. Und stableTypeOrdering macht die Reihenfolge deterministisch, in der der Checker Typen entdeckt; in 6.0 kannst du es per Flag einschalten (es kostet bis zu 25 % Check-Zeit, ist also zur Diagnose deiner Migration da, nicht für den Alltag). In 7.0 ist es immer an und lässt sich nicht abschalten, es ist also eine der Stellen, an denen Ergebnisse von dem abweichen können, was du auf 6.0 gesehen hast.

Eine tsconfig, die auf beiden Versionen läuft, sieht so aus:

tsconfig.json

{

  "compilerOptions": {

    "target": "es2022",

    "module": "esnext",

    "moduleResolution": "bundler",

    "types": ["node"],

    "strict": true,

    "noEmit": true

  },

  "include": ["src"]

}

6.0 brachte außerdem Features, die man kennen sollte und die alle auch auf 7 verfügbar sind: #/-Subpath-Imports, bundler-Resolution zusammen mit commonjs, das Target und die Bibliothek es2025, Temporal-Typen, Map.getOrInsert und RegExp.escape.

Was in TypeScript 7 kaputtgeht

In 6.0 wurde eine Reihe langjähriger Optionen als veraltet markiert und konnte mit "ignoreDeprecations": "6.0" stummgeschaltet werden. In 7.0 gibt es diesen Schalter nicht mehr, und die Optionen sind harte Fehler :

Option oder Syntax	Warum sie geht	Stattdessen
target: "es5"	Veraltetes Ausgabeziel	es2015 oder neuer als Target, und einen Bundler herunterkompilieren lassen, falls du wirklich alte Browser brauchst
downlevelIteration	Nur für Targets unter ES2015 nötig	Entfernen
moduleResolution: "node10" (node) und "classic"	Auflösung aus der Zeit vor ESM	bundler, node16 oder nodenext
module: "amd", "umd", "systemjs", "none"	Überholte Modulformate	esnext oder preserve mit Bundler, oder commonjs
baseUrl	Löst bloße Imports ab der Projektwurzel auf	paths mit expliziten Zuordnungen oder #/-Subpath-Imports
outFile	In 6.0 entfernt	Ein Bundler
esModuleInterop: false, allowSyntheticDefaultImports: false	Interop ist jetzt immer an	Einstellung entfernen
alwaysStrict: false	Strict Mode ist immer an	Einstellung entfernen
module Foo {} für Namespaces	Mehrdeutiges Schlüsselwort	namespace Foo {}
import x from "y" assert { type: "json" }	Durch with ersetzt	with { type: "json" }
tsc datei.ts, obwohl eine tsconfig.json existiert	Man vergisst leicht, dass die Config ignoriert wird	tsc --ignoreConfig datei.ts

Die meisten davon sind Ein-Zeilen-Löschungen. baseUrl ist die Option, die Imports anfasst, und ein kleines Tool, ts5to6, schreibt baseUrl und rootDir für dich um.

Jenseits der Konfiguration haben sich ein paar Verhalten bewusst geändert: Die Inferenz von Template-Literal-Typen behandelt Strings jetzt nach Codepoints, und die JavaScript-Unterstützung hat etwas alte JSDoc- und Closure-Syntax verloren (@enum, @class, Postfix-!, Closure-Funktionstypen). Beides trifft den meisten TypeScript-Code nicht, aber es sind die Stellen, an denen du suchst, wenn nach der Umstellung ein Test ohne Config-Fehler fehlschlägt.

Räum die Deprecations auf 6.0 auf, stelle dann die CI auf den nativen Compiler um und lass Tools, die die Compiler-API brauchen, auf 7.1 warten.

Tooling: Was heute mit 7 funktioniert

Hier trifft „dieselbe Sprache” auf die Realität. TypeScript 7.0 wird ohne programmatische API ausgeliefert, weil der Compiler keine JavaScript-Bibliothek mehr ist, die man per require laden kann. Die Folge ist klar:

Was	Funktioniert auf 7.0?
tsc im Terminal und in der CI	Ja
Type-Checking im Editor für reines TS und TSX	Ja, über den TypeScript-7-Language-Server (eine VS-Code-Erweiterung; Visual Studio aktiviert ihn pro Workspace)
Tools, die import "typescript" nutzen (typescript-eslint, Codemods, Doku-Generatoren)	Nicht direkt; nutze den 6.0-Alias
Language Services für Vue-, MDX-, Astro-, Svelte-, Angular-Templates	Noch nicht
--watch	Ja, auf einem nativen Watcher neu gebaut

Der Workaround ist, beide zu betreiben. Das Paket @typescript/typescript6 liefert den 6.0-Compiler mit einem tsc6-Binary, und mit npm-Aliassen bekommt alles, was typescript importiert, weiter 6.0, während der native Compiler unter eigenem Namen liegt:

package.json

{

  "devDependencies": {

    "typescript": "npm:@typescript/typescript6@^6.0.2",

    "@typescript/native": "npm:typescript@^7.0.2"

  }

}

Beide parallel betreiben, solange du migrierst

npm i -D typescript@7 @typescript/typescript6

npx tsc --noEmit # natives TypeScript 7

npx tsc6 --noEmit # TypeScript 6.0 zum Vergleich

Das installiert beide Kommandozeilen-Tools. Nutze stattdessen die Alias-Form von oben, wenn Tools wie typescript-eslint brauchen, dass import "typescript" zu 6.0 auflöst. In VS Code schaltet der Befehl „Disable TypeScript 7 Language Server” den Editor zurück auf 6.0, falls dir der Language Server mal im Weg steht.

Tipp

Lass tsc6 einige Wochen in der CI mitlaufen und vergleiche die Ausgaben. Jede Datei, in der die beiden abweichen, ist entweder ein Fehler, den du jetzt kennen willst, oder einer, den du melden willst; das hono-Ergebnis oben ist genau der Fall, den das findet.

Dieselbe Disziplin „alt und neu parallel laufen lassen” macht auch andere Toolchain-Wechsel schmerzfrei. So würde ich den Ersatz von ESLint und Prettier durch Biome angehen, und sie hat die Migration von Jest zu Vitest berechenbar gemacht.

Ein sicherer Upgrade-Weg

1. Auf TypeScript 6.0.3 upgraden und pinnen. Behebe die auftretenden Fehler, meist fehlende types-Einträge und strict-Folgen, und committe.
2. Jede Deprecation-Warnung aufräumen. Führe tsc aus und behandle jede Deprecation wie einen Fehler; nutze ts5to6 für baseUrl und rootDir. Greif nicht zu ignoreDeprecations als Endlösung, denn auf 7 bewirkt es nichts.
3. types und rootDir explizit setzen. Das ist der billigste Speedup der ganzen Migration und beseitigt die beiden Standardwerte, die sich am stärksten geändert haben.
4. Optional 6.0 mit --stableTypeOrdering laufen lassen. Es macht die 6.0-Diagnosen auf dieselbe Weise deterministisch wie 7.0, sodass jeder spätere Unterschied vom Port kommt und nicht von der Reihenfolge.
5. TypeScript 7 neben 6 in die CI nehmen. Lass tsc und tsc6 laufen, lass den Build an tsc6 scheitern und melde tsc als nicht blockierenden Job. Lies jede Abweichung.
6. Den blockierenden Check auf 7 umstellen. Behalte den 6.0-Alias für Editoren und jedes Tool, das typescript importiert.
7. Die Parallelität abstimmen. Beginne mit den vier Standard-Checkern; nutze --checkers 2 oder --singleThreaded auf speicherbegrenzten Runnern und --builders bei Monorepos mit Projekt-Referenzen. Lege denselben --checkers-Wert auf jeder Maschine und in der CI fest, denn die Release-Notes warnen, dass eine Änderung in seltenen Fällen reihenfolgeabhängige Ergebnisse sichtbar machen kann.

Wenn du eine Bibliothek pflegst, die die Compiler-API anbietet, oder ein Projekt mit Vue-, Svelte-, Astro- oder Angular-Templates, bleib vorerst bei Schritt 5 stehen. Das ist eine Entscheidung, kein Scheitern.

Was TypeScript 7.1 bringt

TypeScript 7.1 erreichte am 20. Oktober 2026 die Beta, installierbar als typescript@beta, ein Release Candidate wird etwa einen Monat später erwartet. Es ist das Release, das die meisten der obigen Lücken schließt:

• Eine neue Compiler-API mit Einstiegspunkten wie typescript/sync, typescript/ast und typescript/fs, Snapshots, Dateisystem-Schichten und Unterstützung für using.
• Content Mapper , konfiguriert mit contentMappers in der tsconfig.json, für Nicht-TypeScript-Dateien wie Vue, Astro, Svelte und MDX, mit tsc --runExternalCode zum Ausführen.
• Import Attributes in Ambient Modules , die Syntax import source, das Target es2026 und neue Bibliotheksmethoden.
• Weitere Optimierungen , im Benchmark oben sichtbar, und strengeres Prüfen distributiver Typparameter, das in typlastigem Code neue Fehler sichtbar machen kann. Die zusätzlichen hono-Diagnosen habe ich keiner konkreten Änderung zugeordnet, ihre Ursache ist also offen.

Welche Version solltest du nutzen?

Deine Situation	Nutze
Reine TypeScript- oder React-App, CI-Type-Check ist langsam	7.0 für die CI jetzt, nach einem Parallel-Lauf
Großes Monorepo mit Projekt-Referenzen	7.0 , mit --builders und --checkers passend zu deinen Runnern
Vue-, Svelte-, Astro-, MDX- oder Angular-Templates	6.0 für den Editor , 7.0 für CLI-Checks, auf 7.1 warten
Bibliothek oder Tool, das typescript importiert	6.0 , bis die 7.1-API stabil ist
Noch auf target es5, baseUrl, node10-Resolution oder AMD/UMD	Zuerst 6.0 , Deprecations aufräumen, dann 7.0
Speicherbegrenzte CI-Runner	7.0 mit --checkers 2 oder --singleThreaded

Fazit

TypeScript 7 ist dieselbe Sprache mit einer neuen Engine, und die Engine ist das, was du bemerkst: In diesem Test waren Type-Checks 2,9- bis 5,1-mal schneller als auf TypeScript 6, laut Microsofts eigenen Zahlen mit größerem Gewinn bei größeren Codebasen, und die 7.1-Beta ist noch schneller. Der Preis ist eine Migration mit Kanten. Jede Option, die 6.0 als veraltet markierte, ist jetzt ein Fehler, die Compiler-API und die Template-Language-Services müssen auf 7.1 warten, und bei mindestens einem bekannten Projekt sind sich die beiden Compiler über denselben Code uneins. Also: über 6.0 gehen, beide Compiler parallel laufen lassen, zuerst die CI umstellen und den Rest der Toolchain, wenn ihre Unterstützung da ist. Dann dauert das Upgrade einen Nachmittag Konfigurationsarbeit, und du bekommst deine Build-Minuten zurück.

Ursprünglich veröffentlicht auf alekseialeinikov.com