Sollten Sie schon auf TypeScript 7 upgraden?

Steigen Sie jetzt auf TypeScript 7 um, wenn Ihr Projekt aus reinem TypeScript besteht und unter 6.0 bereits fehlerfrei baut. Wenn Sie auf typescript-eslint, Vue, Svelte, Astro, MDX oder die Template-Prüfung von Angular angewiesen sind, betreiben Sie den tsc von 7.0 parallel zu 6.0 und warten Sie mit dem vollständigen Wechsel auf 7.1.

Die Geschwindigkeitswerte sind verlockend. Dann fällt Ihnen ein, dass Ihre Lint-Pipeline, Ihre .vue-Dateien und ein selbst geschriebenes Codegen-Skript allesamt typescript importieren, und ein Major-Versionssprung wirkt plötzlich riskant.

TypeScript 7.0 ist am 8. Juli 2026 erschienen. Dieser Artikel zeigt, wie groß der Geschwindigkeitsgewinn ausfällt, welche Konfigurationsänderungen Ihren Build brechen, welche Tools 7.0 noch nicht nutzen können und wie Sie beide Compiler in einem Repository betreiben. Zum Schluss folgt eine Empfehlung für jede Art von Projekt.

Wie viel schneller ist TypeScript 7?

TypeScript 7.0 ist eine Portierung des TypeScript-Compilers nach Go. Laut Microsoft werden vollständige Builds damit typischerweise 8- bis 12-mal schneller als mit TypeScript 6.0. Das Team hat den Compiler nicht neu entworfen. Die Go-Version bildet Aufbau und Funktionsweise des ursprünglichen Codes nach, sodass beide Compiler dieselben Ergebnisse liefern. Der Gewinn entsteht durch die Ausführung als nativer Code und durch Type-Checking auf mehreren Threads mit gemeinsamem Speicher.

Dies sind die Werte für vollständige Builds aus Microsofts Ankündigung von TypeScript 7.0:

Microsoft hat diese Builds mit der Standardeinstellung von vier Type-Checker-Workern (--checkers 4) auf großen Open-Source-Codebasen ausgeführt. Zur verwendeten Hardware macht die Ankündigung keine Angaben. Das niedrigste Ergebnis, tldraw mit 7,7x, liegt knapp unter der von Microsoft genannten Spanne von „8x bis 12x“.

Wie viel Zeit TypeScript 7 tatsächlich spart, hängt von der Größe Ihrer Codebasis ab. Ausgehend von Microsofts Zahlen spart vscode pro vollständigem Build etwa 115 Sekunden, tldraw weniger als 10. Eine kleine App, deren Type-Check bereits in zwei Sekunden durchläuft, wird um einen ähnlichen Faktor schneller, spart aber kaum Zeit.

Drei kleinere Änderungen, jeweils in einer Zeile:

• --checkers und --builders steuern paralleles Type-Checking bzw. Builds mit Projektreferenzen. Die Release Notes zu 7.0 bezeichnen beide Flags als experimentell.
• --watch basiert jetzt auf einer Go-Portierung des File-Watchers von Parcel.
• Die Prüfung von JS und JSDoc wurde überarbeitet und verhält sich nun stärker wie die Analyse von .ts-Dateien. Details finden Sie in der CHANGES.md von typescript-go.

Was beim Upgrade von TypeScript 5.x oder 6.0 bricht

Code, der unter TypeScript 6.0 mit aktiviertem stableTypeOrdering und ohne ignoreDeprecations fehlerfrei ist, sollte unter TypeScript 7.0 dieselbe Ausgabe liefern. Alles, was bricht, stammt aus 6.0: 7.0 übernimmt die neuen Standardwerte von 6.0, und alles, was 6.0 als veraltet markiert hat, bricht jetzt den Build ab. Teams, die direkt von 5.x kommen, müssen beide Änderungspakete auf einmal bewältigen.

Neue Standardwerte

Vier Standardwerte von TypeScript 7.0, die aus 6.0 übernommen wurden, verursachen die meisten Probleme:

• strict ist true. Rechnen Sie mit neuen Fehlern in locker typisiertem Code. Sauber typisierte Hilfstypen auf Basis der TypeScript Utility Types erleichtern den Übergang.
• module ist standardmäßig esnext.
• rootDir ist standardmäßig ./. Liegt Ihre tsconfig.json oberhalb von src, setzen Sie rootDir explizit.
• types ist standardmäßig []. Führen Sie globale Typpakete wie node oder jest namentlich auf oder setzen Sie ["*"], um das alte Verhalten wiederherzustellen.

Vier weitere Standardwerte haben sich geändert: target folgt jetzt der neuesten fertiggestellten ECMAScript-Edition (eine Stufe hinter esnext), noUncheckedSideEffectImports ist true, libReplacement ist false, und stableTypeOrdering ist true und lässt sich nicht abschalten.

Veraltete Optionen, die jetzt harte Fehler sind

Die Release Notes zu TypeScript 7.0 nennen zwölf veraltete Optionen und Verhaltensweisen, die jetzt zu harten Fehlern führen:

• target: es5
• downlevelIteration
• moduleResolution: node / node10 (stattdessen nodenext oder bundler)
• moduleResolution: classic (stattdessen bundler oder nodenext)
• module: amd, umd, systemjs, none (stattdessen esnext oder preserve)
• baseUrl (paths relativ zum Projektstamm angeben)
• esModuleInterop oder allowSyntheticDefaultImports auf false gesetzt
• alwaysStrict auf false gesetzt
• Das Schlüsselwort module in Namespace-Deklarationen
• asserts bei Imports (stattdessen with)
• /// <reference no-default-lib /> unter skipDefaultLibCheck
• Dateipfade in der Kommandozeile, wenn das Verzeichnis eine tsconfig.json enthält, sofern Sie nicht --ignoreConfig angeben

outFile steht nicht auf dieser Liste, ist aber ebenfalls weg. Laut den Release Notes zu 6.0 wurde es bereits in 6.0 entfernt, und jede in 6.0 als veraltet markierte Option wird in 7.0 vollständig entfernt. Wenn Sie outFile noch nutzen, übertragen Sie diese Aufgabe an einen Bundler.

Hinzu kommt eine Änderung auf Typebene: Beim Inferieren aus Template-Literal-Typen wird ein Zeichen wie ein Emoji nicht mehr in zwei Hälften geteilt. Das bemerken Sie nur, wenn Sie String-Hilfstypen auf Typebene geschrieben haben, die sich auf die alte UTF-16-Aufteilung verlassen.

Hier eine typische Legacy-Konfiguration und die Version, die unter 7.0 funktioniert:

// Before: hard errors on 7.0
{
  "compilerOptions": {
    "target": "es5",               // error: es5 unsupported
    "downlevelIteration": true,    // error: removed
    "moduleResolution": "node",    // error: node/node10 unsupported
    "baseUrl": "./src",            // error: baseUrl unsupported
    "paths": { "@/*": ["*"] }
  },
  "include": ["./src"]
}

// After: valid on 7.0
{
  "compilerOptions": {
    "moduleResolution": "bundler",
    "rootDir": "./src",
    "types": ["node", "jest"],
    "paths": { "@/*": ["./src/*"] }
  },
  "include": ["./src"]
}

Die neue Version lässt target weg, sodass der Standardwert greift, richtet paths am Projektstamm aus und setzt rootDir und types explizit.

Microsoft empfiehlt, zunächst auf 6.0 umzusteigen. Aktualisieren Sie auf 6.0, beheben Sie jede Deprecation-Warnung (die Ankündigung von TypeScript 6.0 erläutert jede einzelne), entfernen Sie ignoreDeprecations und installieren Sie erst dann 7.0.

Welche Tools funktionieren noch nicht mit TypeScript 7?

Tools, die den TypeScript-Compiler als Bibliothek importieren, sowie die Tools hinter der Template-Prüfung von Vue, MDX, Astro, Svelte und Angular funktionieren noch nicht mit TypeScript 7.0, weil TypeScript 7.0 keine programmatische API mitliefert. Laut Microsofts Ankündigung zu 7.0 müssen Tools, die den Compiler als Bibliothek importieren, etwa typescript-eslint, über das Kompatibilitätspaket @typescript/typescript6 weiterhin mit TypeScript 6.0 laufen. Wenn Ihr Setup für typbewusstes Linting mit typescript-eslint auf einer Peer-Dependency auf typescript beruht, benötigt es das im nächsten Abschnitt beschriebene Alias-Setup.

Auch eingebettete Sprachen sind betroffen. Laut Microsofts Ankündigung zu 7.0 sollten Vue-, MDX-, Astro- und Svelte-Projekte vorerst bei TypeScript 6.0 bleiben. Volar und ähnliche Tools integrieren TypeScript-Unterstützung in diese Dateiformate, indem sie den Compiler direkt aufrufen, und 7.0 bietet ihnen keine API dafür. Für die Template-Typprüfung von Angular gilt dieselbe Einschränkung. Für Angular schlägt die Ankündigung eine Aufteilung vor: Verwenden Sie den tsc von 7.0 in der Kommandozeile und in der CI, um Fehler im gesamten Projekt schnell zu finden, und überlassen Sie den Editor weiterhin 6.0, damit die Template-Prüfung funktioniert.

In VS Code bietet Microsofts eigene TypeScript-7-Erweiterung zwei Befehle in der Befehlspalette, „Disable TypeScript 7 Language Server“ und „Enable TypeScript 7 Language Server“, mit denen Sie den Editor jederzeit zwischen 6.0 und 7.0 umschalten können. Verhält sich der Editor nach dem Wechsel merkwürdig, gilt weiterhin der übliche Workflow zum Debuggen von TypeScript in VS Code.

Microsoft plant, in TypeScript 7.1 wieder eine API anzubieten, die allerdings nicht der alten entsprechen wird. Realistisch betrachtet ist dieses Release der Zeitpunkt, zu dem diese Integrationen umziehen.

TypeScript 7 und 6.0 parallel betreiben

Um beide Versionen in einem Repository zu betreiben, verwenden Sie npm-Aliase. Lassen Sie den Paketnamen typescript auf das 6.0-Kompatibilitätspaket zeigen und installieren Sie 7.0 unter einem anderen Namen. Tools, die typescript importieren, laden dann 6.0. Das Kompatibilitätspaket stellt die 6.0-API sowie einen 6.0-Befehl namens tsc6 bereit.

In einem reinen npm-Projekt startet npx tsc dann 7.0. Es gibt allerdings einen Haken: Das Kompatibilitätspaket hängt von einer vollständigen Kopie von TypeScript 6.0 ab, die ihren eigenen tsc deklariert, sodass zwei Pakete um diesen Befehlsnamen konkurrieren. Nutzer haben berichtet, dass Yarn und Bun tsc stattdessen mit 6.0 verknüpfen können. Das folgende typecheck-Skript ruft die 7.0-Datei direkt auf und hängt daher nicht davon ab, welches Paket den Namen tsc erhält. Dies ist das von Microsoft beschriebene Setup, hier ergänzt um Skripte:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  },
  "scripts": {
    "typecheck": "node node_modules/@typescript/native/bin/tsc --noEmit",
    "typecheck:6": "tsc6 --noEmit",
    "lint": "eslint ."
  }
}

typecheck führt 7.0 aus. typecheck:6 führt 6.0 aus, was während der Migration nützlich ist, um zu prüfen, ob beide Compiler übereinstimmen. lint löst typescript über den Alias zu 6.0 auf. Um den 6.0-Alias stattdessen im Terminal einzurichten, führen Sie npm install -D typescript@npm:@typescript/typescript6 aus. Wenn Sie nur das tun, erhalten Sie ausschließlich tsc6; fügen Sie daher auch den 7.0-Alias hinzu.

Führen Sie npx tsc --version aus, um zu sehen, welchen Compiler ein einfaches tsc aufruft. Microsoft dokumentiert dieses Setup nur für npm. Prüfen Sie das Ergebnis daher selbst, wenn Sie pnpm, Yarn oder Bun verwenden.

Sollten Sie upgraden? Die Empfehlung je nach Situation

Ob sich ein Upgrade auf TypeScript 7 lohnt, hängt von zwei Faktoren ab: wie sauber Ihr 6.0-Build ist und ob irgendetwas in Ihrer Toolchain den Compiler importiert.

Neues Projekt: Starten Sie mit 7.0. Wenn Sie von Flow zu TypeScript migrieren, orientieren Sie sich von Anfang an an den Standardwerten von 7.0, damit Sie nicht ein zweites Mal migrieren müssen.

Kleine Codebasis mit reinem TS: Steigen Sie auf 6.0 um, beheben Sie alle Deprecations und wechseln Sie dann. Die Zeitersparnis wird gering sein, aber Sie befinden sich auf der gepflegten Versionslinie.

Großes Monorepo: Richten Sie den Alias ein, verlagern Sie das Type-Checking in der CI schon jetzt auf den tsc von 7.0 und belassen Sie Linting, Codegen und Editor bei 6.0, bis 7.1 seine API mitbringt.

Fazit

TypeScript 7.0 prüft Ihren Code nahezu genauso wie 6.0, nur schneller. Fast alles, was bricht, geht auf die Deprecations von 6.0 oder auf Tools zurück, die eine Compiler-API benötigen. Sorgen Sie zunächst für einen sauberen Build unter 6.0 ohne ignoreDeprecations. Anschließend wechseln Sie entweder vollständig oder fügen den npm-Alias hinzu und lassen die CI den tsc von 7.0 ausführen, während Ihr Tooling bis 7.1 bei 6.0 bleibt.

FAQs

Sind tsgo oder @typescript/native-preview dasselbe wie TypeScript 7?

Nicht mehr. Vor dem Release von 7.0 wurde der Go-Compiler im Paket @typescript/native-preview als Vorschau bereitgestellt, und sein Befehl lautete tsgo. Die letzte Version dieses Pakets ist 7.0.0-dev.20260707.2, veröffentlicht am Tag vor dem stabilen Release. In TypeScript 7.0 befindet sich der native Compiler im regulären Paket typescript und wird als tsc ausgeführt. Nightly Builds kommen jetzt aus typescript@next. Ersetzen Sie daher tsgo in Ihren CI-Skripten durch tsc.

Macht TypeScript 7 Builds mit Vite, esbuild oder SWC schneller?

Nein. Vite, esbuild und SWC wandeln TypeScript in JavaScript um, indem sie die Typen entfernen, ohne sie zu prüfen. Sie rufen tsc also nie auf, und ihre Transpilierzeiten bleiben unverändert. TypeScript 7 beschleunigt den separaten Type-Check-Schritt, meist tsc --noEmit in der CI oder in einem Pre-Commit-Hook, sowie den Language Server im Editor. Wenn das Type-Checking nicht der langsamste Schritt in Ihrer Pipeline ist, werden Ihre Builds durch das Upgrade nicht spürbar kürzer.

Funktioniert ts-node mit TypeScript 7?

Nicht direkt. ts-node kompiliert Dateien über die TypeScript-Compiler-API, und 7.0 liefert diese API nicht mit. Mit dem npm-Alias-Setup wird der Import von typescript in ts-node zum 6.0-Kompatibilitätspaket aufgelöst, sodass ts-node weiterhin mit 6.0 läuft, während tsc mit 7.0 läuft. Für Code, der ausschließlich entfernbare Syntax verwendet, kann das Type Stripping aktueller Node.js-Versionen .ts-Dateien ganz ohne Compiler ausführen, führt dabei aber kein Type-Checking durch.

Kann TypeScript 7 noch nach ES5 für ältere Browser kompilieren?

Nein. TypeScript 6.0 hat das niedrigste unterstützte Target auf ES2015 angehoben und target es5 als veraltet markiert. In 7.0 führt target es5 zu einem harten Fehler. Wenn Sie weiterhin ES5-Ausgabe benötigen, lassen Sie tsc ES2015 oder neuer erzeugen und verarbeiten Sie das Ergebnis mit Babel oder einem anderen Compiler nach. Alternativ kompilieren Sie den TypeScript-Quellcode direkt mit diesem externen Tool.