Startseite / Artikel / TypeScript 6's Bridge Role in the Path to a Native TS 7 Compiler

Dieser Artikel ist auf Englisch veröffentlicht.

TypeScriptJavaScriptCompilersNode.jsToolingPerformance

TypeScript 6's Bridge Role in the Path to a Native TS 7 Compiler

Learn how TypeScript 6 updates default configs, module resolution, and import syntax to prepare codebases for the faster, Go-based TypeScript 7 compiler.

2201 Wörter

Jeder Entwickler, der eine umfangreiche TypeScript-Codebasis verwaltet, kennt dieses vertraute Verzögerungseffekt. Wenn man speichern klickt, pausiert der Editor für einige Sekunden, während der Language Server aufholen muss. In CI-Pipelines stapeln sich Pull Requests, da allein die Typüberprüfung fünf bis zehn Minuten in Anspruch nehmen kann.

Entwickler speichert Datei ──> [ JS-basierter tsc: Einfachthreadige Verarbeitung ] ──> Langsame Rückmeldung
Entwickler speichert Datei ──> [ TS 7 Native Engine: Parallelisierte Threads ] ──> Sofortige Rückmeldung

TypeScript 7 stellt einen in Go entwickelten nativen Compiler vor. Er verarbeitet Aufgaben über mehrere Threads und verkürzt die Build-Zeiten um das Acht- bis Zehnfache. Doch man kann keinen mehrthreadigen nativen Compiler einfach in ein Projekt einfügen, das noch auf Konfigurationsoptionen aus dem Jahr 2018 angewiesen ist.

Das ist der Zweck von TypeScript 6: Es dient als Übergangspunkt. Es beseitigt veraltete technische Schulden, aktualisiert veraltete Standardeinstellungen und sorgt dafür, dass Ihr Projekt nach dem Erscheinen von TypeScript 7 reibungslos kompiliert wird.

Warum braucht TypeScript eine Brückenversion?

Mehr als zehn Jahre lang wurde der TypeScript-Compiler selbst in TypeScript geschrieben und auf Node.js ausgeführt. Dadurch konnten JavaScript-Entwickler direkt zum Codebase des Compilers beitragen.

Das Problem ist jedoch, dass die Ausführung in JavaScript eingleisig erfolgt. Als die Codebases zu riesigen Monorepos mit Millionen von Zeilen anwuchsen, stieß der Compiler schließlich an eine starre Leistungsgrenze.

TypeScript 7 löst dieses Problem, indem es natives Maschinencode in Parallel über mehrere CPU-Kerne ausführt. Allerdings führt ein parallelisierter Compiler zu zwei Verhaltensanforderungen, die zuvor keine Rolle spielten:

Deterministische Sortierung: Selbst wenn mehrere Kerne Typen gleichzeitig auswerten, muss der Compiler garantieren, dass gemeldete Fehler und abgeleitete Typen stets in einer konsistenten, wiederholbaren Reihenfolge erzeugt werden.
Anpassung an moderne Standards: Die weiterhin Unterstützung jahrzehntealter Modulsysteme wie AMD oder veralteter Lösungsstrategien fügt einem nativen Compiler unnötige Komplexität und Overhead hinzu.

TypeScript 6 markiert den Punkt, an dem das Team diese Erwartungen durchsetzt. Es lenkt Entwickler in Richtung der aktuellen ECMAScript-Vorgaben, damit der Übergang zur Version 7 keine Störungen verursacht.

Die größten Konfigurationsänderungen in `tsconfig.json`

Die meisten sichtbaren Änderungen in TypeScript 6 befinden sich innerhalb Ihrer tsconfig.json-Datei. Mehrere seit Langem gültige Standardwerte wurden aktualisiert, um den heutigen Build-Prozessen von Projekten Rechnung zu tragen.

1. `strict: true` ist nun Standard

Zuvor bedeutete eine leere tsconfig.json-Datei, dass TypeScript im permissiven Modus arbeitete, es sei denn, Sie wählten manuell "strict": true aus.

Ab TypeScript 6 wird der strenge Modus automatisch aktiviert.

// tsconfig.json
{
 "compilerOptions": {
 // Dies ist in TypeScript 6 standardmäßig aktiv
 "strict": true
 }
}

Falls Ihr Projekt bereits mit strict: true konfiguriert ist, ändert sich für Sie nichts. Wenn Ihr Code jedoch auf implizite any-Typen oder unüberwachte null- und undefined-Werte angewiesen ist, werden bei einem Upgrade sofort Typfehler sichtbar.

Warum das wichtig ist:

Ein eingebauter Typprüfer arbeitet am effizientesten, wenn die Typinformationen explizit und konsistent sind. Lockerer Typing zwingt den Compiler, mit unvorhersehbaren Fallback-Szenarien umzugehen, was die statische Analyse verlangsamt.

2. Der Standardzielmodus für Module ist `esnext`

TypScript verwendete historisch gesehen ältere Ausgabeziele wie ES3 oder ES5. In der Praxis sind nahezu alle heute in der Produktion eingesetzten Laufzeiten „evergreen“ – Node.js, Bun, Deno sowie moderne Browser unterstützen alle native ECMAScript Modules.

Mit TypeScript 6 ist die Standardoption für module nun esnext, und die Standardwert für target verweist auf eine aktuelle ECMAScript-Version.

// Empfohlene moderne Einstellung
{
 "compilerOptions": {
 "module": "esnext",
 "moduleResolution": "bundler", // oder "nodenext"
 "target": "es2024">
 }
}

Falls Ihre Anwendung weiterhin eine CommonJS-Ausgabe benötigt, um ältere Serverumgebungen zu unterstützen, können Sie weiterhin selbst "module": "commonjs" festlegen. TypeScript geht davon aus, dass kein veraltetes Ausgabeformat verwendet wird, es sei denn, Sie fordern dies explizit an.

Klareere Modulgrenzen: Auf `baseUrl`-Tricks verzichten

Einst war es üblich, dass Teams Pfade in einer Konfiguration wie folgt als Aliase einrichteten:

// Altes Muster in tsconfig.json
{
 "compilerOptions": {
 "baseUrl": "./",
 "paths": {
 "@components/*": ["src/components/*"],
 "@services/*": ["src/services/*"]
 }
 }
}

Ältere TypeScript-Versionen erforderten das Vorhandensein von baseUrl, damit überhaupt paths-Einstellungen verarbeitet werden konnten. Diese Anforderung stellte ein Problem dar, da baseUrl es Entwicklern außerdem ermöglichte, Importe ohne relativen Präfix zu schreiben – wie zum Beispiel import { Button } from "src/components/Button" – was es schwierig machte, lokale Projektdateien von aus npm heruntergeladenen Paketen zu unterscheiden.

TypeScript 6 beseitigt diese Abhängigkeit: paths kann nun eigenständig verwendet werden, ohne dass eine baseUrl-Deklaration erforderlich ist. Darüber hinaus fügt TypeScript 6 eine native Unterstützung für Node.js-Subpfad-Importe hinzu, wobei dabei die Konvention mit einem #-Präfix verwendet wird.

Natürliche Subpfad-Importe verwenden

Anstatt auf typspezifische Aliasierung in TypeScript zu setzen, können aktuelle Projekte vom standardmäßigen imports-Feld in package.json profitieren:

// package.json
{
 "name": "my-app",
 "imports": {
 "#services/*": "./src/services/*.js",
 "#utils/*": "./src/utils/*.js"
 }
}

In Ihren Quelldateien referenzieren Sie diese Subpfade mithilfe der standardmäßigen #-Syntax:

// src/api/user.ts
import { db } from "#services/database";
import { formatName } from "#utils/string";

export function getUser(id: string) {
 const user = db.find(id);
 return formatName(user.name);
}

Da dieses Verfahren von Node.js selbst verstanden wird und keine Umwandlung auf der Compilerseite erfordert, wird die Dateiabfrage sowohl bei TypeScript 6 als auch beim kommenden TypeScript 7 deutlich schneller.

Wortwörtliche Modulsyntax und Typ-einziges Importieren

Ein häufiges Problem in Codebasen, die Laufzeitcode mit Typdeklarationen mischen, ist, dass Importe, die nur Typinformationen enthalten, versehentlich als echte, ausführbare Importe behandelt werden können. Wenn man eine Schnittstelle über einen gewöhnlichen import-Befehl einbindet, muss jedes Tool, das diese Datei liest, selbst herausfinden, ob der Import tatsächliche JavaScript-Logik enthält oder lediglich Typinformationen für die Kompilierzeit.

TypeScript 6 ermutigt Teams dazu, verbatimModuleSyntax zu aktivieren:

// tsconfig.json
{
 "compilerOptions": {
 "verbatimModuleSyntax": true
 }
}

Wenn diese Option aktiviert ist, wird die Regel eindeutig: Alles, was rein typbezogen ist, muss mit dem Schlüsselwort import type importiert werden.

// ZUVOR: Der Compiler musste überprüfen, ob User und Order Laufzeitcode enthielten
import { User, Order, calculateTotal } from "./billing";

// NACHHER: Explizit und vorhersehbar für Compiler sowie Bundler
import { calculateTotal } from "./billing";
import type { User, Order } from "./billing";

Warum ist das für TypeScript 7 wichtig?

Der kommende, mehrkernige, parallelisierte Compiler versucht, Dateien immer dann isoliert zu verarbeiten, wenn es möglich ist. Ein import type-Statement teilt ihm sofort mit, dass dort nichts JavaScript-Output erzeugen wird, sodass er es vermeiden kann, ./billing.ts zu öffnen und zu analysieren, nur um die Ausgaberegeln für die aktuelle Datei herauszufinden. Diese kleine Disziplin führt zu deutlich geringerem Build-Aufwand bei großen Codebasen.

Neuere eingebaute Sprachergonomien

Neben den Konfigurationsstandards bringt TypeScript 6 eine Reihe alltäglicher Erleichterungen mit, die es ermöglichen, gängige Codemuster einfacher zu schreiben.

1. `Map.getOrInsert()` und `Map.getOrInsertComputed()`

Denken Sie daran, wie oft Sie bereits solche wiederholten Cache-Lookup-Logiken schreiben mussten:

// Die alte, wiederholende Methode
const userCache = new Map<string, UserProfile>>();

function getProfile(userId: string): UserProfile {
 let profile = userCache.get(userId);

 if (!profile) {
 profile = fetchProfileFromDatabase(userId);
 userCache.set(userId, profile);
 }

 return profile;
}

TypeScript 6 unterstützt die von TC39 vorgeschlagene getOrInsertComputed-Methode, mit der Sie dieses Muster durch folgendes ersetzen können:

// Die moderne TypeScript 6-Methode
const userCache = new Map<string, UserProfile>>();

function getProfile(userId: string): UserProfile {
 // Der Callback wird nur ausgeführt, wenn der Schlüssel noch nicht existiert
 return userCache.getOrInsertComputed(userId, () => {
 return fetchProfileFromDatabase(userId);
 });
}

Diese Version ist kompakter, vermeidet den Bedarf an einer veränderbaren Platzhaltervariable und hält die Typinferenz stets präzise.

2. Ein integriertes Typdefinition für `RegExp.escape()`

Die Sanitierung von Sonderzeichen vor deren Einbetten in eine reguläre Ausdruck musste früher entweder durch das Schreiben eigener Hilfsfunktionen oder durch den Einsatz von Drittanbieter-Paketen erfolgen. TypeScript 6 bietet nun eingebaute Typdefinitionen für RegExp.escape():

const userInput = „item.value [test]“;

// Sicherer Umgang mit Zeichen wie '.', '[' und ']'
const safePattern = RegExp.escape(userInput);
const regex = new RegExp(`^${safePattern}

  
    
    
    
    
    Operator Software for Solar, BESS & Video | REACTAPP.TOP
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    TypeScript 6's Bridge Role in the Path to a Native TS 7 Compiler
    
    
    
    
  
  
    );

Durch diese Lösung können Sie eine ganze Klasse von Fehlern durch Regex-Injection vermeiden, ohne zusätzliche Abhängigkeiten in Ihr Projekt aufzunehmen.

Vorbereitung auf deterministische Typreihenfolge

Eine unauffälligere, aber wichtige Ergänzung in TypeScript 6 ist die Flagge stableTypeOrdering.

Bis TypeScript 5.x hing die Reihenfolge, in der Mitglieder eines Union-Typs angezeigt wurden, davon ab, in welcher Reihenfolge der Compiler die Dateien im Speicher verarbeitete. Da die Kompilierung auf einem einzigen Thread stattfand, blieb diese Reihenfolge in der Regel von Ausführung zu Ausführung konstant.

Sobald man jedoch zu einem parallelisierten Compiler wie dem für TypeScript 7 geplanten wechselt, können die Worker-Threads ihre zugewiesenen Aufgaben jedes Mal in einer anderen Reihenfolge erledigen. Wenn ein Thread vor einem anderen fertig wird, kann die Ergebnisart als string | number auftreten; führt man den Build erneut aus oder auf einem anderen Rechner durch, erhält man möglicherweise stattdessen number | string.

Damit die generierten .d.ts-Dateien nicht unvorhersehbar wechseln, wendet TypeScript 7 intern eine strenge, deterministische Sortierregel an. In TypeScript 6 kann man bereits jetzt dieses Verhalten aktivieren:

// tsconfig.json
{
 "compilerOptions": {
 "stableTypeOrdering": true
 }
}

Falls Ihre Arbeit darin besteht, Open-Source-Pakete zu warten oder generierte Deklarationsdateien in ein Versionierungssystem einzuspeichern, lohnt es sich, diese Einstellung zu aktivieren und sie bereits heute auszuprobieren. Dadurch wird sichergestellt, dass Ihre Snapshot-Tests sowie die erzeugten Typen keine sinnlosen Unterschiede liefern, sobald Sie schließlich auf TypeScript 7 wechseln.

Praktische Migrations-Checkliste

Der Umstieg auf eine neuere Version bei einer umfangreichen Codebasis muss nicht schwierig sein, wenn Sie ihn schrittweise angehen. Berücksichtigen Sie folgende Prioritäten:

Überprüfen Sie zunächst jede mit strict verbundene Einstellung, da dies Ihre beste Verteidigung gegen implizite any-Werte sowie ungeschützte null-Referenzen ist, bevor Version 7 verfügbar wird – hohe Priorität. Entfernen Sie veraltete Modulkonfigurationen und wechseln Sie von AMD, UMD sowie der herkömmlichen node-Modulauflösungsstrategie ab – hohe Priorität. Aktivieren Sie verbatimModuleSyntax, damit die Erstellung von JavaScript nicht mehr vom Typprüfer abhängt – mittlere Priorität. Führen Sie Importe über Unterpfade mit dem Präfix # ein, wodurch umständliche Lösungen für die Pfadauflösung spezifischer Bundler entfallen – mittlere Priorität. Legen Sie rootDir explizit fest, um Überraschungen in der Struktur Ihres Ausgabeverzeichnisses bei parallelen Builds zu vermeiden – niedrige Priorität.

Häufige Fehler, die vermieden werden sollten

Fehler 1: Striktes Modus deaktivieren, um Upgrade-Fehler zu beheben

Ein häufiger Reflex nach dem Aufstieg auf TypeScript 6 und dem Auftreten einer Welle neuer Fehler ist es, einfach "strict": false zu setzen, damit die kontinuierliche Integration wieder funktioniert.

Diese Lösung kann kurzfristig dazu führen, dass man wieder weiterarbeiten kann, verschoben aber nur die eigentliche Arbeit. Die Leistungsverbesserungen von TypeScript 7 basieren auf der Annahme einer zuverlässigen Typisierung. Anstatt den strengen Modus vollständig auszuschalten, deaktivieren Sie vorübergehend einzelne Überprüfungen – beispielsweise "noImplicitAny": false – und beseitigen Sie die dadurch entstehenden Fehler schrittweise, Datei für Datei.

Fehler 2: Mischen von Laufzeit- und Typimporten

Kombinieren Sie keine Typ- und Wertimporte in einer einzigen Anweisung, sobald verbatimModuleSyntax aktiviert ist:

// Vermeiden
import { User, UserService } from "./userService";

// Vorziehen
import { UserService } from "./userService";
import type { User } from "./userService";

Durch die Trennung wird klar – sowohl für Leser als auch für den Compiler –, welche Imports nur zum Typüberprüfen dienen und welche tatsächlichen Laufzeitcode enthalten.

Das große Bild: Was kommt als Nächstes?

TypeScript 6 versucht nicht, Ihnen eine Menge neuer Syntax zum Lernen zu präsentieren. Sein eigentlicher Zweck ist es, den Grundstein für einen noch größeren Wandel zu legen.

Durch das Aktualisieren Ihres tsconfig.json jetzt, den Wechsel zu expliziten Importen nur mit Typangaben sowie das Beseitigen der alten Art des Pfadmanagements beseitigen Sie den überwiegenden Teil der Probleme, mit denen Sie sonst später konfrontiert wären. Sobald TypeScript 7 verfügbar ist, bedeutet das Upgrade im Grunde nur noch ein Anheben der Paketversion und den Einsatz des neuen nativen Compilers – wodurch die Kompilierzeit auf deutlich unter eine Sekunde sinkt und es nicht notwendig ist, Ihren vorhandenen Code umzuschreiben.

Nehmen Sie sich diese Woche etwas Zeit, um die Konfiguration Ihres Projekts zu überprüfen. Es handelt sich dabei um eine kleine Investition, die sich später erheblich auszahlen wird.

Welcher Plan haben Sie für das Upgrade?

Führt Ihr Team bereits im strengen Modus, oder müssen Sie noch ältere Konfigurationsoptionen auflösen? Haben Sie bereits mit Subpath-Importen in Ihren eigenen Projekten experimentiert? Teilen Sie Ihre Gedanken und Fragen in den Kommentaren mit.