---
title: "TypeScript 7 vs. TypeScript 6: Was sich ändert, was kaputtgeht und wie das Upgrade gelingt"
description: "TypeScript 7 ist dieselbe Sprache auf einem neuen, nativen Compiler in Go. Was sich zwischen TypeScript 6 und 7 ändert, ein eigener Benchmark mit type-fest, kysely und hono, jede Option, die jetzt ein harter Fehler ist, die Tools, die noch nicht funktionieren, und ein sicherer Upgrade-Weg über 6.0, mit Blick auf die 7.1-Beta."
author: Aleksei Aleinikov
date: 2026-10-21
lang: de
tags: [typescript-7, typescript-6, tsgo, typescript-go, typescript-native-compiler, typescript-migration, typescript-performance]
canonical: https://www.alekseialeinikov.com/de/blog/topics/programming/typescript-7-vs-typescript-6-nativer-compiler-upgrade-leitfaden
source: alekseialeinikov.com
---

# 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: dieselbe Sprache auf einem neuen nativen Compiler, gemessen an echten Open-Source-Projekten.](https://www.alekseialeinikov.com/blog/typescript-7-vs-6.webp)

## 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](https://devblogs.microsoft.com/typescript/announcing-typescript-6-0/) und [7.0](https://devblogs.microsoft.com/typescript/announcing-typescript-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:

![TypeScript 7 vs. 6 Build-Pipeline: ein JavaScript-Thread gegen nativen Code mit parallelem Parsen, vier Checker-Workern und parallelem Emit, plus die Flags, die das steuern.](https://www.alekseialeinikov.com/blog/typescript-7-pipeline.webp "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?](https://www.alekseialeinikov.com/de/blog/topics/programming/wie-viele-threads-nutzt-go-wirklich-runtime-untersuchung-2026).

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](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) 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](https://github.com/LF3551/typescript-7-vs-6-benchmark). 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×** |

![TypeScript 7 vs. 6 Benchmark mit type-fest, kysely und hono: Type-Checks sind mit TypeScript 7.0.2 2,9- bis 5,1-mal schneller, die Single-Thread-Balken zeigen, wie viel allein vom nativen Code kommt.](https://www.alekseialeinikov.com/blog/typescript-7-benchmark.webp "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.

> [!WARNING]
> 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.

> [!NOTE]
> 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](https://github.com/LF3551/typescript-7-vs-6-benchmark) 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:

```json title="tsconfig.json" {5-6}
{
  "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.

![TypeScript-Upgrade-Weg von 5.9 über 6.0.3 zu 7.0 und 7.1, mit den Optionen, die zu harten Fehlern werden, und den Tools, die heute umstellen können.](https://www.alekseialeinikov.com/blog/typescript-7-upgrade-path.webp "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:

```json title="package.json" {3-4}
{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.2",
    "@typescript/native": "npm:typescript@^7.0.2"
  }
}
```

```bash title="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.

> [!TIP]
> 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](https://www.alekseialeinikov.com/de/blog/topics/programming/biome-2026-eslint-prettier-ersetzen-benchmark) angehen, und sie hat die [Migration von Jest zu Vitest](https://www.alekseialeinikov.com/de/blog/topics/programming/von-jest-zu-vitest-migrieren) 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](https://devblogs.microsoft.com/typescript/announcing-typescript-7-1-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.