TypeScript 7 im Projekt — Cheat Sheet

Zum Danebenlegen beim Konfigurieren, Migrieren und Prüfen: welcher Schalter wofür, in welcher Reihenfolge der Wechsel läuft, wonach ein Review generierten Codes zuerst sucht. Die Typseite — Grundtypen, Unions, Generics, Validierung — steht auf dem Blatt TypeScript 7 Typsystem.

Maßgeblich sind die TypeScript-Dokumentation und die Release Notes zu 6.0 und 7.0; dieses Blatt ist eine Auswahl. Stand der Werkzeuglage: 08/2026 — der Punkt, der hier am schnellsten veraltet, ist die fehlende Compiler-API.

Drei Versionen, drei Aufgaben

6.0 meldet als Warnung, was 7.0 als Fehler abweist — die Deprecation-Liste aus 6.0 ist damit die Arbeitsliste für 7.0. Der Sprung von 5.x direkt auf 7.0 bündelt zwei Umstellungen zu einer.

Modul: TypeScript 7 im JavaScript-Ökosystem

Was der native Compiler gemessen bringt

Zahlen des TypeScript-Teams aus der Ankündigung vom 08.07.2026, Prisma nach eigener Angabe. Das sind Messungen an fremden Projekten, keine Zusage — Prisma nennt den Grund für den kleineren Faktor selbst: Nur ein Teil der CI-Zeit steckte je in tsc.

Neben der Buildzeit gemessen: 18 bis 26 Prozent weniger Speicher, über 80 Prozent weniger fehlgeschlagene Language-Server-Kommandos, über 60 Prozent weniger Abstürze, Öffnen einer Datei mit Fehler von 17,5 s auf unter 1,3 s. Der vollständige Build läuft selten, der Language Server dauernd.

Modul: TypeScript 7 im JavaScript-Ökosystem · Performance Engineering

tsc: drei Aufgaben, ein Werkzeug

"scripts": {
  "typecheck": "tsc --noEmit",
  "build": "tsc",
  "test": "vitest run",
  "ci": "npm run typecheck && npm test && npm run build"
}

typecheck als eigenes Skript ist die Voraussetzung dafür, dass Pipeline und Coding Agent die Prüfung einzeln aufrufen können.

Modul: TypeScript 7 im JavaScript-Ökosystem · ESM, Module und moderne Toolchains

Modulauflösung: was gilt, was entfiel

Die Wahl folgt einer einzigen Frage: Wer führt den Code am Ende aus?

Seit 6.0 neu erlaubt: moduleResolution: bundler zusammen mit module: commonjs. Falsch wird es erst, wenn dasselbe Projekt beide Annahmen zugleich trifft.

Modul: ESM, Module und moderne Toolchains

ESM gegen CommonJS, type-only Imports

import type { Auftrag } from "./auftrag.js";   // verschwindet zuverlässig
import { lade } from "./auftrag.js";

verbatimModuleSyntax macht die Trennung verbindlich: Was im Quelltext steht, steht auch im Ergebnis. Ein Modul, das nur Typen liefert, wird dann zur Laufzeit nicht geladen — und Nebenwirkungen beim Import werden weder zufällig ausgelöst noch verschluckt.

Modul: ESM, Module und moderne Toolchains

package.json als Modulvertrag

{
  "type": "module",
  "exports": { ".": "./dist/index.js" },
  "imports": { "#domaene/*": "./dist/domaene/*" }
}

Subpath Imports (#domaene/auftrag.js) löst Node selbst auf — sie gelten also auch zur Laufzeit, anders als paths ohne Bundler oder Loader. Fehlt exports, ist der gesamte Dateibaum öffentlich.

Anwendung ist nicht Bibliothek:

Modul: ESM, Module und moderne Toolchains

Migration: die Reihenfolge und ihr Grund

stableTypeOrdering kostet bis zu 25 Prozent Prüfzeit und wird nach dem Wechsel wieder entfernt. Der Compilerwechsel selbst ändert am Code nichts — die Arbeit steckt in den geänderten Voreinstellungen aus 6.0.

Modul: Migration auf TypeScript 7

Geänderte Voreinstellungen ab 6.0

Praktische Folge: types und rootDir gehören jetzt in jede tsconfig, die Node-Globals braucht oder eine vorhersehbare Ausgabestruktur will. Was Default ist, gehört dagegen nicht in die Datei — sie wird sonst unlesbar.

{
  "compilerOptions": {
    "module": "nodenext",
    "types": ["node"],
    "rootDir": "./src",
    "outDir": "./dist",
    "declaration": true
  },
  "include": ["src"]
}

Modul: Migration auf TypeScript 7 · TypeScript 7 im JavaScript-Ökosystem

Was verschwindet, was an die Stelle tritt

Für die mechanische Arbeit an baseUrl und rootDir gibt es ein Werkzeug — in der Quelle als experimentell gekennzeichnet, und die Architekturfrage, ob paths überhaupt bleiben sollen, liefert es nicht mit:

npx @andrewbranch/ts5to6 --fixBaseUrl .
npx @andrewbranch/ts5to6 --fixRootDir .

Modul: Migration auf TypeScript 7

Zwei benannte Verhaltensunterschiede

Gezielt danach suchen heißt: Snapshot-Tests über Fehlermeldungen zuerst laufen lassen, generierte Deklarationen vor und nach dem Wechsel vergleichen, beide Compiler dieselbe Codebasis prüfen lassen.

Modul: Migration auf TypeScript 7

Die fehlende Compiler-API und der Parallelbetrieb

TypeScript 7.0 bringt keine Compiler-API mit; sie ist für 7.1 vorgesehen, aber nicht datiert. Betroffen ist jedes Werkzeug, das den Compiler als Bibliothek einbindet:

Prüffrage: Steht typescript in den Abhängigkeiten des Werkzeugs? Dann betroffen. Bis dahin der Parallelbetrieb — tsc prüft nativ, die Werkzeuge importieren weiter die 6er-API:

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

--force oder --legacy-peer-deps bringen die API nicht hervor.

Modul: Architektur, Qualität und Tests · Migration auf TypeScript 7

Performance-Flags

tsc                          # Standard: vier Prüf-Worker
tsc --checkers 8             # mehr Worker, mehr Speicher
tsc --checkers 1             # einer, für Diagnose und Vergleich
tsc --build --builders 4     # Teilprojekte nebenläufig
tsc --build --builders 4 --checkers 2   # wirkt multiplikativ

Mehr Prozesse können langsamer sein: Jeder Worker hält eine eigene Sicht auf die Typinformation im Speicher; reicht der nicht, lagert das System aus. Und der Gewinn von --builders hängt an der Form des Abhängigkeitsgraphen, nicht an der Zahl der Pakete — erst die Referenzen schneiden, dann die Flags drehen.

Modul: Performance Engineering

Quality Gates

Ein rotes Tor blockiert — sonst ist es kein Tor, sondern ein Hinweis. Und derselbe Befehl muss lokal laufen wie in der Pipeline, sonst gilt er als Schikane.

Type-level und Runtime beantworten verschiedene Fragen:

// @ts-expect-error  — darf nicht übersetzen, cent fehlt
const kaputt: Auftrag = { nummer: nr };
expect(summe([a, b])).toBe(17800);

Modul: Architektur, Qualität und Tests

Coding Agents: Stufen und geeignete Aufgaben

Zwei Fragen entscheiden über die Eignung einer Aufgabe — ist sie beschreibbar, und ist das Ergebnis maschinell prüfbar?

Ein Auftrag hat vier Teile: Ziel (was geändert wird), Kontext (welche Dateien, Beispiele, Fehler zählen), Randbedingungen (Standards, Architektur, Sicherheit) und Abschlusskriterium (was wahr sein muss). Fehlt das letzte, ist fertig, was fertig aussieht.

Modul: Von AI-assisted Coding zu Agentic Coding

Repository Instructions

Was über der Obergrenze liegt, geht verloren — unsichtbar und ungemeldet.

Prüffrage je Zeile: Würde ihr Fehlen zu Fehlern führen? Wenn nein, streichen. Wird eine Regel trotz Nennung missachtet, ist die Datei meist zu lang.

Modul: Repository Instructions und Guardrails

Beratend oder verbindlich

Eine Bitte in der Anweisungsdatei ist keine Zugriffskontrolle. Die Datei bleibt trotzdem nötig — sie erklärt das Warum, das eine Sperre nicht mitliefert.

Modul: Repository Instructions und Guardrails

Review eines generierten Diffs

Konfiguration zuerst, dann der Code — eine entschärfte Konfiguration hebt die Aussagekraft aller übrigen Prüfungen auf:

git diff -- tsconfig.json eslint.config.*
git diff | grep -nE ": *any|as +[A-Z]|![.)]"

Der Unterschied zwischen gelöst und verborgen an einem Beispiel — beide Fassungen übersetzen:

const summe = auftrag.cent! + gebuehr;             // verborgen
if (auftrag.zustand !== "freigegeben") return;     // gelöst
const summe = auftrag.cent + gebuehr;

Was im generierten Code regelmäßig fehlt:

Und ein Test, der nichts prüft, bleibt grün:

expect(rabatt(10000)).toBe(10000 * 0.9);   // baut die Implementierung nach
expect(rabatt(10000)).toBe(9000);          // nennt das erwartete Ergebnis

Modul: Qualitätssicherung KI-generierten Codes

Generierte Typmodelle prüfen

Der Vorschlag, der überall auftaucht — target: es5 und moduleResolution: node sind seit 6.0 Fehler, baseUrl entfällt in 7.0, strict ist Voreinstellung. Der Grund ist der Kalender: 6.0 kam im März 2026, 7.0 am 8. Juli 2026; Trainingsdaten davor kennen überwiegend die 5.x-Ära.

Aus fünf Beispielantworten lässt sich Optionalität nicht ableiten, nur beobachten — der Vorschlag ist ein Anfang, kein Ergebnis. Und: Ein Assistent schlägt für eine fachliche Regel meist nur den Typ vor; die Laufzeitprüfung fehlt und fällt nicht auf.

Modul: KI-gestützte Typmodellierung

Typische Fallen

• ignoreDeprecations auf 6.0 setzen und die Arbeit für erledigt halten.
• Von 5.x direkt auf 7.0 springen — zwei Umstellungen in einer.
• Umstellen, obwohl Vue, Svelte, Astro, MDX oder Angular-Templates im Spiel sind. Sie brauchen die Compiler-API.
• Einen Migrationstermin zusagen, bevor die Werkzeuge geprüft sind — und einen Termin für 7.1 gibt es nicht.
• Defaults ausschreiben, bis die tsconfig unlesbar ist; oder types weglassen und sich über unbekannte Node-Globals wundern.
• paths behalten ohne Bundler oder Loader — der Compiler löst auf, die Laufzeit nicht.
• Die Dateiendung im Import weglassen, weil es beim Übersetzen funktioniert.
• Die Typprüfung im Build-Schritt verstecken oder nur im Editor laufen lassen. Ein erfolgreicher Bundler-Lauf bedeutet keine geprüften Typen.
• Ein Tor abschalten, weil die Werkzeuglage klemmt, ohne es zu vermerken.
• Faktor 10 versprechen und Faktor 3 liefern — fremde Messungen sind keine Zusage für die eigene Codebasis.
• --checkers hochdrehen, ohne den Speicher des CI-Läufers zu kennen.
• Der Zusammenfassung eines Agenten glauben, ohne den Diff geöffnet zu haben.
• Jeden Befund eines Prüfers abarbeiten — wer beauftragt ist, Lücken zu finden, findet welche. Das erzeugt Über-Engineering.
• Prüfen lassen von derselben Sitzung, die den Code geschrieben hat.
• Abdeckungsgrad als Qualitätsmaß nehmen — er misst Ausführung, nicht Prüfung.
• Sperren nur aufschreiben, ohne sie technisch zu verankern. Fremde Inhalte im Repository sind nicht vertrauenswürdiger als eine Netzantwort — belegt durch CVE-2025-53773 (Command Injection, CVSS 7,8 laut Hersteller): Die Anweisung steckte in Dateien des Arbeitsbereichs und änderte die Konfiguration so, dass Aktionen nicht mehr bestätigt wurden.