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

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:

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.

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:

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.

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:

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:

{
  "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:

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.

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:

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:

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.2",
    "@typescript/native": "npm:typescript@^7.0.2"
  }
}

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.

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?

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.