TypeScript 6.0 RC: Funktionen, grundlegende Änderungen und Vorbereitung

Startseite » Python » TypeScript 6.0 RC: Funktionen, grundlegende Änderungen und Vorbereitung

TypeScript 6.0 hat offiziell den Meilenstein Release Candidate (RC) erreicht.Und es handelt sich nicht einfach nur um ein weiteres inkrementelles Update. Dies ist die letzte Hauptversion, die auf der langjährigen JavaScript-Implementierung des Compilers und des Sprachdienstes basiert, kurz bevor das Projekt auf eine brandneue, Go-basierte Engine in TypeScript 7.0 umsteigt. Allein das macht Version 6.0 zu einer entscheidenden Veröffentlichung: Sie ist die Brücke, die Sie überqueren müssen, bevor sich alles im Hintergrund ändert.

Sie können die RC-Version noch heute testen, indem Sie sie über npm installieren. mit:

npm install -D typescript@rc

Die Kernidee von TypeScript 6.0 ist Vorbereitung und Ausrichtung.Diese Version ebnet den Weg von 5.9 zu 7.0, indem sie Standardeinstellungen optimiert, veraltete Funktionen entfernt und einige gezielte Features hinzufügt, die entweder zukünftiges Verhalten widerspiegeln oder kommende JavaScript-Funktionen wie Temporal, ES2025-APIs und Map-Upsert-Methoden bereitstellen. Dabei gibt es einige subtile Anpassungen am Typsystem, neue Compiler-Flags und Konfigurationsvorgaben, die sich definitiv auf reale Projekte auswirken werden – insbesondere im Bereich der Veröffentlichung von 7.0. types, rootDirund Strenge.

TypeScript 6.0 als Brücke zu Go-basiertem 7.0

TypeScript 6.0 ist ausdrücklich als letzte Hauptversion der bestehenden JavaScript-Codebasis konzipiert.Das TypeScript-Team hat den Compiler und den Sprachdienst in eine neue Version umgeschrieben. motor nativo en GoDie neue Engine nutzt native Leistung und Shared-Memory-Parallelität. Sie wird mit TypeScript 7.0 und höher eingeführt, Version 6.0 dient als Übergangsphase.

Die meisten der in Version 6.0 enthaltenen Änderungen und veralteten Funktionen dienen dazu, ein zukünftiges Upgrade auf Version 7.0 zu ermöglichen.Optionen, die in der nativen Architektur, alten Modulsystemen und langjährigen Eigenheiten nicht effizient unterstützt werden können, werden entweder entfernt oder klar als veraltet gekennzeichnet, wobei eine Ausweichmöglichkeit besteht: Sie können einstellen "ignoreDeprecations": "6.0" in Ihrem tsconfig.json Um die Diagnose veralteter Funktionen in Version 6.0 zu unterdrücken. Diese Option wird Ihnen in Version 7.0 jedoch nicht mehr helfen – diese Optionen sollen komplett verschwinden.

Wenn Sie in Versuchung geraten, mit Konfigurationsbereinigungen „auf Version 7.0 zu warten“, dann ist das eine Falle.Die Version 6.0 RC ist die Version, in der Sie Ihre Probleme beheben sollen. tsconfigTypen normalisieren und veraltete Flags behandeln. Zwei große Sprünge (5.x → 7.0) sind immer schmerzhafter als ein schrittweiser Übergang von 5.x → 6.0 → 7.0 mit kleineren, kontrollierten Änderungen.

Was hat sich seit der Betaversion 6.0 geändert?

Zwischen der Beta- und der Release Candidate-Phase konzentrierte sich das TypeScript-Team hauptsächlich darauf, das Verhalten an die zukünftige 7.0-Engine anzupassen.sowie einige gezielte Anpassungen bei der Typüberprüfung und den DOM-Typisierungen.

Eine wichtige Änderung betrifft die Typüberprüfung von Funktionsausdrücken, die an generische Aufrufe übergeben werden.Dies gilt insbesondere für JSX-Kontexte. Wenn generische Funktionen mit Callbacks aufgerufen werden (beispielsweise in React oder anderen JSX-Komponenten), verschärft der RC die Typinferenz, um das Verhalten von Version 7.0 genauer widerzuspiegeln. In der Praxis werden Sie feststellen, dass einige Aufrufe, die bisher auf impliziter Typinferenz basierten, nun ein explizites Typargument benötigen, damit die Typprüfung weiterhin erfolgreich ist. Gleichzeitig werden Sie aber auch mehr echte Fehler in bestehendem Code aufdecken.

Die Abschaffung der Syntax für Import-Assertions wurde ebenfalls erweitert.TypeScript warnte bereits vor dem alten import ... assert {...} Syntax in statischen Importen aufgrund des ECMAScript-Vorschlags, der auf Importattribute umstellt withDiese Veraltung gilt nun auch für dynamische Importe. import() mit Assertionsobjekten wie import(..., { assert: {...}})Die Richtung ist klar: Überall sollen Importattribute eingeführt werden.

Die DOM-Bibliothekstypen wurden aktualisiert, um den aktuellen Webplattformstandards zu entsprechen.Dies umfasst Aktualisierungen der temporalbezogenen APIs im Webkontext. Bei der Entwicklung von Browseranwendungen profitieren Sie von präziseren Typisierungen und verbesserten Editorwerkzeugen für diese neueren APIs.

Weniger Kontextsensitivität für Funktionen, die nie verwendet werden this

TypeScript 6.0 führt eine subtile, aber sehr praktische Änderung in der Behandlung von Funktionen ohne expliziten Parameter ein. this Verwendung während der TypinferenzHistorisch gesehen konnten Funktionen mit Parametern ohne explizite Typen als „kontextsensitiv“ betrachtet werden, was bedeutete, dass ihre Parameter und this Die Typen hängen davon ab, wo sie verwendet werden. Das beeinflusst die generische Inferenz und kann je nach Funktionssyntax zu unerwartetem Verhalten führen.

Betrachten wir einen generischen Helfer, der ein Produzenten- und ein Konsumentenpaar verwendet.:

declare function callIt<T>(obj: {
  produce: (x: number) => T,
  consume: (y: T) => void,
}): void;

// Arrow functions: everything infers fine
callIt({
  produce: (x: number) => x * 2,
  consume: y => y.toFixed(),
});

// Flipped property order still fine with arrows
callIt({
  consume: y => y.toFixed(),
  produce: (x: number) => x * 2,
});

Bei Verwendung der Methodensyntax könnte das bisherige Verhalten jedoch überraschend sein.Dieselbe Logik, als Methoden geschrieben, könnte fehlschlagen, wenn Eigenschaften neu angeordnet werden, da TypeScript „kontextsensitive“ Funktionen beim Ableiten generischer Argumente überspringt. Methoden haben implizit einen this Parameter, der sie in diese sensible Kategorie einordnete, selbst wenn this wurde nie konkret erwähnt.

In Version 6.0 wurden Funktionen, die nie gelesen wurden, entfernt. this werden nun als weniger kontextsensitiv behandelt.Anders ausgedrückt: Wenn der Compiler feststellt, dass this Wird `this` innerhalb einer Funktion überhaupt nicht verwendet, hat dies keine negativen Auswirkungen auf die Funktion bei der Inferenz. Das bedeutet, dass Methodensyntax und Pfeilsyntax in generischen Inferenzszenarien nun deutlich konsistenter sind und das seltsame Verhalten „funktioniert in einer Eigenschaftsreihenfolge, schlägt aber in einer anderen fehl“ in diesen Fällen verschwindet.

Diese Änderung verbessert die Priorisierung von Kandidaten für die Typinferenz.: Funktionen ohne Verwendung this werden zu Informationsquellen mit höherer Priorität beim Ableiten von Typargumenten wie TDer Effekt ist weniger mysteriös. unknown Typen und eine stabilere Inferenz über Refaktorierungen hinweg. Diese Arbeit wurde von Mateusz Burzyński beigetragen.

Unterstützung für Node #/ Unterpfad-Importe

Die Node-Funktion „Subpath Imports“ ermöglicht es Paketen, interne Import-Aliase über die imports Feld in package.jsonDiese Aliase vereinfachen Importe, indem sie tiefe relative Pfade vermeiden. Zuvor musste jeder Unterpfadschlüssel mindestens ein Segment nach dem ersten Pfad enthalten. #Dies war eine kleine, aber ärgerliche Einschränkung für Leute, die an Bundler-Konventionen wie diese gewöhnt waren. @/....

TypeScript 6.0 unterstützt nun Unterpfadimporte, die mit einem #/Dies entspricht dem Verhalten von Node 20. Das bedeutet, dass Sie beispielsweise folgende Konfiguration verwenden können:

{
  "name": "my-package",
  "type": "module",
  "imports": {
    "#": "./dist/index.js",
    "#/*": "./dist/*"
  }
}

Mit dieser Konfiguration können Module innerhalb des Pakets – und sogar Konsumenten – über eine prägnante Schnittstelle importieren. #/... Präfix statt langer relativer Pfade wie ../../utils.jsTypeScript versteht dieses Muster, wenn --moduleResolution eingestellt ist node20, nodenextden bundlerDies spiegelt die Semantik des modernen Node wider. Diese Erweiterung wurde vom Mitwirkenden magic-akari implementiert.

Die Verwendung von --moduleResolution bundler und --module commonjs

Zuvor --moduleResolution bundler konnte nur verwendet werden mit --module esnext or preserveMit der Abschaffung der älteren node/node10 Im Modulauflösungsmodus benötigten viele Projekte einen Migrationspfad, der zu ihrer aktuellen CommonJS-Ausgabe passte.

TypeScript 6.0 erlaubt nun die Kombination --moduleResolution bundler und --module commonjsDiese Kombination ist oft ein praktischer Zwischenschritt für Codebasen, die noch CommonJS ausgeben, aber auf Bundler-zentrierte Workflows oder neuere Auflösungslogik umsteigen. Von dort aus können Projekte eine längerfristige Migration zu Folgendem planen:

• module: "preserve" und moduleResolution: "bundler" für gebündelte Web-Apps und ähnliche Setups, oder
• module: "nodenext" für Umgebungen, die direkt auf modernes Node.js abzielen.

Diese Änderung ist besonders relevant für Teams, die ausscheiden moduleResolution: node hinter Wir sind aber noch nicht bereit, die Ergebnisse von ESM vollständig zu nutzen. Es bietet Ihnen einen schrittweisen Weg anstelle eines abrupten Abbruchs.

Das --stableTypeOrdering Flagge zur Emulation der 7.0-Reihenfolge

Eine der wichtigsten architektonischen Verbesserungen in TypeScript 7.0 ist die parallele Typüberprüfung.Die parallele Ausführung mehrerer Prüfroutinen ermöglicht es, verschiedene Programmteile in unterschiedlicher Reihenfolge zu durchlaufen. Wenn Typ-IDs und Symbolreihenfolge von der Aufrufreihenfolge abhängen, kann dies zu nicht-deterministischer Union- und Eigenschaftsreihenfolge sowie zu seltenen Unterschieden in der Diagnose führen.

Ältere TypeScript-Versionen weisen interne Typ-IDs basierend auf der Reihenfolge der Typbegegnungen zu.Diese IDs werden dann verwendet, um Dinge wie Union-Typen und Eigenschaften zu sortieren. Deshalb können scheinbar harmlose Änderungen – wie das Einführen eines neuen const vor einer bestehenden Funktion – kann die Reihenfolge von Literal-Vereinigungen in den ausgegebenen Daten umkehren .d.ts Dateien oder ändern Sie die Art und Weise, wie bestimmte Dateitypen in Ihrem Editor gedruckt werden.

TypeScript 7.0 wechselt zu einer deterministischen, inhaltsbasierten Ordnung für interne Objekte.Jeder Typ oder jedes Symbol wird gemäß seiner Struktur sortiert, nicht nach der zufälligen Reihenfolge des Zugriffs. Daher erzeugt dasselbe Programm unabhängig von Parallelität oder Kompilierungsreihenfolge stets dieselbe Sortierung. Das beseitigt das Rätsel „Warum hat sich meine Union plötzlich umgekehrt?“.

Um Ihnen den Vergleich des Verhaltens zwischen Version 6.0 und 7.0 zu erleichtern, führt die RC Folgendes ein: --stableTypeOrderingWenn dieses Flag aktiviert ist, verwendet TypeScript 6.0 denselben deterministischen Typordnungsalgorithmus wie Version 7.0. Dies führt zu deutlich weniger Unterschieden in den generierten Deklarationsdateien und besser vorhersagbaren Vergleichen zwischen den Ausgaben von Version 6.x und 7.x.

Der Determinismus ist jedoch nicht frei. Aktivieren --stableTypeOrdering Die Typüberprüfung kann je nach Codebasis um bis zu 25 % verlangsamt werden. Sie dient als Diagnose- und Migrationshilfe und ist keine dauerhaft aktivierte Leistungseinstellung.

Wenn Sie nur Typfehler sehen, wenn --stableTypeOrdering Ist eingeschaltetDas bedeutet in der Regel, dass Ihr bisheriger Code sich auf die alte, quasi zufällige Reihenfolge der Typen für die Typinferenz verlassen hat, damit diese einfach funktionierte. Die Behebung besteht typischerweise darin, Typen explizit zu machen – beispielsweise durch Hinzufügen eines Typarguments zu einem problematischen generischen Aufruf oder durch Annotation einer Variablen mit einer spezifischen Schnittstelle, anstatt sich bei einem komplexen Objekt ausschließlich auf die Typinferenz zu verlassen.

New es2025 Ziel- und Bibliotheksoptionen

TypeScript 6.0 fügt eine es2025 Option für beide target , libES2025 führt zwar keine neue Kernsyntax im Vergleich zu den Vorjahren ein, integriert aber mehrere standardisierte APIs, die zuvor nur eingeschränkt zugänglich waren. esnext.

Durch gezielte Maßnahmen oder Einbeziehung es2025Sie erhalten aktualisierte Typdefinitionen für neue integrierte Funktionen. Google Trends, Amazons Bestseller RegExp.escapeund einige APIs wurden ausgelagert esnext in es2025Das umfasst Dinge wie Promise.try, Iterator-Helfer und zusätzliche Set Methoden, die den vollen Spezifikationsreifegrad erreicht haben. Dieser Beitrag stammt von Kenta Moriuchi.

Die übergeordnete Botschaft ist, dass die Standardeinstellung target In Version 6.0 wird nun das aktuelle ECMAScript-Jahr berücksichtigt.Das führt derzeit dazu, dass man ohne Angabe eines Ziels effektiv auf ES2025 landet. Das entspricht besser der Realität von Evergreen-Laufzeitumgebungen und modernen Werkzeugen.

Eingebaute Typen für die Temporal-API

Der lang erwartete Vorschlag von Temporal hat die dritte Phase erreicht und soll voraussichtlich das berüchtigte System ersetzen. Date API für anspruchsvolle Datums-/ZeitverarbeitungTypeScript 6.0 bietet nun erstklassige Typdefinitionen für Temporal, sodass Sie mit dem Schreiben von Temporal-basiertem Code mit voller Typsicherheit und Editorunterstützung beginnen können.

Um temporale Datentypen zu aktivieren, können Sie Folgendes verwenden: --target esnext oder konfigurieren Sie Ihre Bibliotheken explizit etwa so:

{
  "compilerOptions": {
    "lib": 
  }
}

Oder Sie können sich nur für die zeitliche Teilmenge entscheiden mit "esnext.temporal" Wenn Sie eine detailliertere Konfiguration wünschen. Sobald dies aktiviert ist, können Sie Code in etwa so schreiben:

let yesterday = Temporal.Now.instant().subtract({
  hours: 24,
});

let tomorrow = Temporal.Now.instant().add({
  hours: 24,
});

console.log(`Yesterday: ${yesterday}`);
console.log(`Tomorrow: ${tomorrow}`);

Temporal wird bereits von einigen Laufzeitumgebungen unterstützt und kann in anderen per Polyfill implementiert werden.Diese Typen sind also bereits heute nutzbar. Die Dokumentation dazu wird auf MDN veröffentlicht (einige Lücken werden jedoch noch geschlossen). Die Typdefinitionen wurden vom GitHub-Nutzer Renegade334 beigesteuert.

Upsert-Unterstützung: Map.getOrInsert , getOrInsertComputed

JavaScript-Entwickler haben manuell „check‑then‑set‑then‑get“-Muster geschrieben auf Map jahrelangEin typisches Muster prüft, ob ein Schlüssel existiert, setzt andernfalls einen Standardwert und gibt schließlich einen Wert zurück – Standardcode, der leicht Fehler verursachen oder überall wiederholt werden kann.

Der ECMAScript-„Upsert“-Vorschlag (jetzt Phase 4) führt Folgendes ein: getOrInsert , getOrInsertComputed on Map , WeakMapTypeScript 6.0 fügt Typunterstützung für diese Methoden hinzu. esnext lib, damit Sie sofort mit dem Schreiben deklarativer Upserts beginnen können.

Mit getOrInsertein so ausführliches Muster wie dieses:

function processOptions(compilerOptions: Map<string, unknown>) {
  let strictValue: unknown;
  if (compilerOptions.has("strict")) {
    strictValue = compilerOptions.get("strict");
  } else {
    strictValue = true;
    compilerOptions.set("strict", strictValue);
  }
  // ...
}

Kann zu einer einzigen Zeile zusammengefasst werden.:

function processOptions(compilerOptions: Map<string, unknown>) {
  let strictValue = compilerOptions.getOrInsert("strict", true);
  // ...
}

Der Begleiter getOrInsertComputed ist ideal für teure ZahlungsausfälleEs benötigt eine Callback-Funktion, die nur aufgerufen wird, wenn der Schlüssel fehlt. Diese Callback-Funktion kann den Schlüssel sogar als Parameter erhalten, sodass sich der Standardwert vom Schlüssel selbst ableiten lässt. Die Typdefinitionen von TypeScript bilden dieses Verhalten präzise ab, auch dank der Beiträge von Renegade334.

RegExp.escape und sicherere Regex-Erstellung

Wenn Sie jemals benutzerdefinierte Zeichenketten in einen regulären Ausdruck eingebunden haben, wissen Sie, dass Sie Sonderzeichen zuerst maskieren müssen.Die meisten Codebasen implementieren das Escaping entweder in einer Hilfsfunktion neu oder verzichten ganz darauf. Der RegExp-Escaping-Vorschlag (jetzt Phase 4) standardisiert dies mit RegExp.escape.

TypeScript 6.0 stellt Typen für RegExp.escape unter dem es2025 libDas bedeutet, dass Sie beim Verwenden von ES2025 als Ziel oder Einbindung von ES2025 bedenkenlos Hilfsfunktionen wie die folgenden schreiben können:

function matchWholeWord(word: string, text: string) {
  const escapedWord = RegExp.escape(word);
  const regex = new RegExp(`\\b${escapedWord}\\b`, "g");
  return text.match(regex);
}

Eine manuell betätigte Auslösefunktion ist nicht mehr nötig.TypeScript wird die API vollständig verstehen und typüberprüfen. Diese Ergänzung stammt, wie auch die Arbeit am ES2025-Zielstandard, von Kenta Moriuchi.

dom Die Bibliothek enthält nun APIs für Iteration und asynchrone Iteration.

Historisch gesehen hat TypeScript die Unterstützung für DOM-Iteratoren aufgeteilt in dom, dom.iterable und dom.asynciterableWenn Sie iterativ vorgehen wollten NodeList or HTMLCollection und for...ofMan musste daran denken, hinzuzufügen dom.iterable in Ihrem "lib" Konfiguration neben domDies war eine häufige Quelle der Verwirrung, insbesondere da alle modernen Browser iterierbare Objekte und asynchrone iterierbare Objekte auf DOM-Sammlungen unterstützen.

In TypeScript 6.0, lib.dom.iterable.d.ts , lib.dom.asynciterable.d.ts werden effektiv verschmolzen in lib.dom.d.tsDas bedeutet, dass man "dom" alone bietet Ihnen jetzt standardmäßig iterierbares und asynchrones iterierbares Verhalten.

Sie können es immer noch erwähnen dom.iterable , dom.asynciterable in Ihrem tsconfigDiese Dateien sind nun jedoch leere Hüllen. Wenn Ihre vorherige Konfiguration so aussah:

{
  "compilerOptions": {
    "lib": 
  }
}

Sie können getrost vereinfachen auf nur "dom"und Iteration über DOM-Sammlungen wie document.querySelectorAll("div") wird weiterhin eine Typprüfung durchführen:

for (const element of document.querySelectorAll("div")) {
  console.log(element.textContent);
}

Dies ist eine kleine, aber willkommene Aufräumaktion. Dadurch wird die Standard-DOM-Bibliothek an die Realität aktueller Browser angepasst und eine weitere Stolperfalle bei der Projekteinrichtung beseitigt.

Standardeinstellungen, veraltete Funktionen und grundlegende Änderungen in TypeScript 6.0

Abgesehen von den neuen APIs enthält Version 6.0 einige der grundlegendsten Änderungen an den TypeScript-Standardeinstellungen seit Version 1.0.Diese Änderungen spiegeln das aktuelle JavaScript-Ökosystem wider: Evergreen-Laufzeitumgebungen, ESM als Basis, weitverbreitete Verwendung von Bundlern und ein starkes Bedürfnis nach strikter Typisierung und Leistung.

Das Team hebt einige allgemeine Trends hervor, die diesen Entscheidungen zugrunde liegen.ES5 und wirklich veraltete Browser sind fast verschwunden; AMD/UMD-Modulsysteme sind Nischenprodukte; fast alles wird heute als Modul ausgeliefert; strikte Typisierung ist die Norm; und die Leistung muss im Vordergrund stehen, insbesondere da Version 7.0 parallele Überprüfungen einführt.

Daher werden TypeScript 6.0 und 7.0 mit modernen Standardeinstellungen und weniger „Altlasten-Ausweichmechanismen“ gestaltet.In Version 6.0 RC können Sie veraltete Funktionen vorübergehend unterdrücken, indem Sie die entsprechende Einstellung vornehmen. "ignoreDeprecations": "6.0" in Ihrem tsconfigDiese Optionen wird es in Version 7.0 jedoch nicht mehr geben. Einige Anpassungen lassen sich mit Tools wie dem experimentellen Tool automatisieren. ts5to6 codemod, das beim Umschreiben von Dingen wie diesen helfen kann baseUrl , rootDir Konfigurationen innerhalb eines Projekts.

Zwei Anpassungen, die viele Projekte sofort benötigen werden

Obwohl die Liste der veralteten Funktionen lang ist, dürften zwei Konfigurationsänderungen die meisten Codebasen betreffen.:

• explizit festlegen types Array (sehr oft) sowie Ihrem Testframework). Ohne dies verlieren Sie automatisch eingebundene Umgebungstypen von @types/*.
• Explizit festgelegt rootDir (häufig "./src") Wenn Sie sich auf die alte Methode der „gemeinsamen Stammverzeichnisableitung“ verlassen haben. Andernfalls könnte sich die Struktur Ihrer erzeugten Datei auf subtile Weise verändern.

Symptome des Fehlens types einschließlich einer Flut von Fehlern über globale Variablen wie process, fs, pathden describe undefiniertSymptome einer veränderten rootDir geht es eher darum, dass Ausgabepfade unerwartet einen zusätzlichen Wert erhalten. src Segment (zum Beispiel) dist/src/index.js statt dist/index.js).

Aktualisierte Standardeinstellungen für moderne Projekte

Mehrere Compileroptionen haben nun neue Standardwerte, die der tatsächlichen Vorgehensweise beim Erstellen der meisten neuen Anwendungen entsprechen.:

• strict ist nun standardmäßig auf trueDer strikte Modus ist keine optionale Funktion mehr, sondern die Standardeinstellung. Wenn Sie bisher den nicht-strikten Modus verwendet haben, müssen Sie ihn nun explizit aktivieren. "strict": false (Allerdings entgeht Ihnen dadurch eine große Kategorie von Sicherheitsüberprüfungen).
• module ist nun standardmäßig auf esnextDies spiegelt wider, dass ESM das vorherrschende Modulformat ist und am besten mit Bundlern und modernen Node-Versionen zusammenarbeitet.
• target Standardmäßig wird das aktuelle ECMAScript-Jahr verwendet (derzeit effektiv ES2025).in der Annahme, dass die meisten Bereitstellungen auf Evergreen-Umgebungen abzielen oder über einen Bundler erfolgen, der bei Bedarf noch weiter heruntergestuft werden kann.
• noUncheckedSideEffectImports ist jetzt true standardmäßig, wodurch Sie Tippfehler oder fehlerhafte Pfade in Importen aufspüren können, die nur aufgrund von Nebeneffekten eingebunden sind.
• libReplacement Standardmäßig ist falseDadurch werden zahlreiche zusätzliche fehlgeschlagene Modulauflösungen und Überwachungs-Overhead vermieden, bis ein Projekt explizit auf spezialisierte Bibliotheksverhaltensweisen setzt.

Falls eine dieser neuen Standardeinstellungen Ihren Build beeinträchtigt, können sie alle explizit überschrieben werden in tsconfig.jsonDie Absicht ist jedoch, dass neue Projekte „einfach das Richtige tun“ sollen, ohne zusätzliche Konfiguration.

rootDir Standardmäßig wird nun das Konfigurationsverzeichnis verwendet.

Bisher, wenn Sie nichts angegeben haben rootDirTypeScript versuchte, einen gemeinsamen Quellcodestamm abzuleiten. Basierend auf allen Nicht-Deklarationsdateien im Programm. Das erschwerte die Bestimmung der Projektgrenzen und erforderte das Durchsuchen vieler Dateipfade, nur um zu entscheiden, wo „emit“ seinen Ursprung haben sollte.

In TypeScript 6.0 ist der Standardwert rootDir ist einfach das Verzeichnis, das enthält tsconfig.jsonDas alte Inferenzverhalten gilt nur, wenn Sie Folgendes ausführen tsc auf der Kommandozeile ohne jegliche tsconfig überhaupt.

Diese Änderung bedeutet, dass Projekte, deren Quelldateien sich tiefer als das Konfigurationsverzeichnis befinden, dies explizit festlegen sollten. rootDirEine gängige Konfiguration wäre:

{
  "compilerOptions": {
    // ...
    "rootDir": "./src"
  },
  "include": 
}

Wenn Ihre Konfiguration auf Dateien oberhalb der tsconfig Standortabhängig müssen Sie außerdem erweitern rootDir entsprechendBeispielsweise "rootDir": "../src" für gemeinsam genutzte Quellverzeichnisse.

types Standardmäßig wird nun ein leeres Array verwendet.

Dies ist wohl die wirkungsvollste Änderung für reale Projekte.Früher galt: Wenn Sie nichts spezifizierten types in compilerOptionsTypeScript würde automatisch alles unterhalb von einbinden node_modules/@typesDas war zwar praktisch, aber auch teuer und fehleranfällig: Moderne Repositories laden oft Hunderte von Dateien hoch. @types Pakete transitiv.

In TypeScript 6.0, types Standardmäßig ist []Das bedeutet, dass keine Umgebungspakete automatisch geladen werden.Sie wählen nun explizit die globalen Umgebungen aus, die Sie tatsächlich benötigen, zum Beispiel:

{
  "compilerOptions": {
    "types": 
  }
}

Dies kann die Bauzeiten bei manchen Projekten um 20-50 % verkürzen.weil der Compiler nicht mehr jede Deklarationsdatei durchsuchen muss unter @typesWenn Sie wirklich das alte Verhalten „Alles laden“ beibehalten möchten, können Sie Folgendes angeben:

{
  "compilerOptions": {
    "types": 
  }
}

Wenn plötzlich Fehlermeldungen wie „Name 'process' nicht gefunden“ oder „Modul 'fs' nicht gefunden“ angezeigt werdenDas ist Ihr Stichwort zum Hinzufügen. node (und alle anderen Test-/Laufzeittypen, auf die Sie sich verlassen) zu Ihrem types Array.

Veraltet: target: es5 , --downlevelIteration

Die Ausrichtung auf ES5 ist veraltet.Da alle relevanten Browser seit Jahren ES2015+ unterstützen und der Internet Explorer eingestellt wurde, lohnt sich die zusätzliche Komplexität der ES5-Ausgabe innerhalb von TypeScript nicht mehr. Die niedrigste unterstützte Zielversion ist zukünftig ES2015. Falls Sie unbedingt ES5 verwenden müssen, empfiehlt sich die Nutzung eines externen Transpilers (wie Babel oder einer Bundler-Pipeline) entweder für Ihren TypeScript-Quellcode oder für die TypeScript-Ausgabe.

Das --downlevelIteration Das Flag ist ebenfalls veraltet.da sein einziger sinnvoller Anwendungsfall darin bestand, das Ausgabeverhalten für ES5-Ziele anzupassen. In TypeScript 6.0 wird die Einstellung downlevelIteration Die Verwendung des Flags führt zu einem Deprecation-Fehler. Wenn Sie ES2015 oder neuer verwenden, hatte das Flag ohnehin nie eine Auswirkung.

Veraltet: --moduleResolution node und Vermächtnis classic

Das node (aka node10Der Modulauflösungsmodus ist veraltet.Es modellierte das Verhalten von Node 10, entspricht aber nicht der modernen ESM- und Auflösungssemantik von Node.js. Projekte sollten zu einer der beiden folgenden Versionen migrieren: nodenext (für direkte Node-Ziele) oder bundler (für Bundler-gesteuerte Umgebungen wie Web-Apps oder Bun).

Das Original moduleResolution: classic Die Strategie wurde ebenfalls entfernt.Dies war die Geschichte der TypeScript-Lösung vor Node.js. Heute werden alle praktischen Anwendungsfälle besser durch … abgedeckt. nodenext or bundlerUm Komplexität und Sonderfälle zu reduzieren, wird auf klassisches Design verzichtet.

Veraltet: AMD, UMD, SystemJS und module: none

Folgende module Diese Werte sind nun veraltet und werden nicht mehr unterstützt.:

• amd
• umd
• systemjs
• none

Diese Formate waren in der Zeit vor dem ESM von entscheidender Bedeutung.Als Browser noch keine native Modulunterstützung boten, griffen Entwickler auf AMD, UMD oder SystemJS zurück, um diese Lücke zu schließen. Heute decken ESM plus Bundler oder Import-Maps praktisch alle Anwendungsfälle ab, und „keiner“ war nie wirklich klar definiert.

Wenn Sie immer noch diese älteren Modulformate verwenden.Die Empfehlung lautet daher, auf ein ESM-erzeugendes Zielsystem umzusteigen und für die finale Paketierung einen Bundler oder alternativen Compiler zu verwenden – oder bei TypeScript 5.x zu bleiben, bis ein Migrationsplan vorliegt. Im Zuge dieser Bereinigung wird die alte amd-module Die Anweisung wird ebenfalls fallen gelassen.

Veraltet: baseUrl

Das baseUrl Die Option ist seit langem eine Quelle für seltsames, schwer zu debuggendes Modulauflösungsverhalten.Viele Projekte verwendeten es lediglich als Präfix für paths Einträge, aber TypeScript behandelte es auch als allgemeines Suchverzeichnis, was zu Importen wie führte "someModule" sich dazu entschließen src/someModule.js unerwartet, obwohl der Entwickler lediglich benutzerdefinierte Aliase unterstützen wollte, wie @app/*.

In 6.0, baseUrl ist veraltet und wird nicht mehr als Nachschlagestamm verwendet.Die Pfadzuordnung war nicht erforderlich. baseUrl schon seit geraumer Zeit, daher besteht die empfohlene Migration einfach darin, das Präfix in jedes einzelne Element einzufügen. paths Eintrag. Zum Beispiel:

// Before
{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": {
      "@app/*": ,
      "@lib/*": 
    }
  }
}

// After
{
  "compilerOptions": {
    "paths": {
      "@app/*": ,
      "@lib/*": 
    }
  }
}

Nur in seltenen Fällen, in denen Sie es wirklich verwendet haben baseUrl als generische Nachschlagewurzel Müsste man dieses Verhalten mit einer allgemeinen Pfadzuordnung wie der folgenden reproduzieren:

"paths": {
  "*": ,
  "@app/*": ,
  "@lib/*": 
}

Für die meisten Teams reicht es aus, einfach zu entfernen baseUrl und Inline-Präfixe in paths wird sowohl klarer als auch sicherer sein..

Interoperabilität und Strenge: esModuleInterop, allowSyntheticDefaultImports und alwaysStrict

TypeScript 6.0 legt außerdem das seit langem empfohlene Standard-Interoperabilitätsverhalten fest.Sie können nicht mehr einstellen esModuleInterop or allowSyntheticDefaultImports zu falseDiese Optionen waren ursprünglich optional, um Probleme mit älteren Projekten zu vermeiden. Werden sie heutzutage jedoch deaktiviert, führt dies häufig zu subtilen Laufzeitproblemen bei der Kombination von CommonJS und ESM.

Wenn die Interoperabilität immer aktiviert ist, müssen bestimmte Importmuster möglicherweise aktualisiert werden.. Zum Beispiel:

// Old style with esModuleInterop: false
import * as express from "express";

// New style with modern interop always on
import express from "express";

Das alwaysStrict Das Flag kann auch nicht gesetzt werden auf false nicht mehrTypeScript setzt nun durchgängig die Semantik des strikten JavaScript-Modus voraus, einschließlich der Behandlung von reservierten Wörtern und this Verhalten Sie sich entsprechend. Wenn Sie wirklich alten Code haben, der reservierte Wörter wie z. B. verwendet, dann sollten Sie sich entsprechend verhalten. await or static Da es sich um Kennungen handelt, müssen Sie diese umbenennen.

Veraltet: outFileLegacy-Namensraum module Schlüsselwort und Import asserts

Das --outFile Diese Option wurde in Version 6.0 entfernt.Das Zusammenfügen mehrerer Eingabedateien zu einem einzigen JS-Bundle ist eine Aufgabe, die besser von Webpack, Rollup, esbuild, Vite, Parcel oder ähnlichen Tools erledigt wird. TypeScript setzt verstärkt auf Typüberprüfung und Deklarationsausgabe, anstatt selbst als Bundler zu fungieren.

Die traditionelle Verwendung von module Das Deklarieren von Namensräumen ist nun ein schwerwiegender Fehler.. Frühe TypeScript-Versionen erlaubten:

module Foo {
  export const bar = 10;
}

Die moderne, unterstützte Syntax verwendet namespace:

namespace Foo {
  export const bar = 10;
}

Diese Änderung ist notwendig, um Konflikte mit potenziellen zukünftigen ECMAScript-Versionen zu vermeiden. module Blöcke. Ambient-Moduldeklarationen wie declare module "some-module" { ... } bleiben uneingeschränkt unterstützt.

Importieren Sie Assertions mit asserts sind ebenfalls veraltetweil sich der zugrunde liegende Vorschlag zur Verwendung von Importattributen weiterentwickelt hat withCode wie:

import blob from "./data.json" asserts { type: "json" };

Sollte in das neue Formular migriert werden:

import blob from "./data.json" with { type: "json" };

Veraltet: no-default-lib Referenzen und Befehlszeilendateilisten mit tsconfig

Das /// <reference no-default-lib="true" /> Die Direktive wird nicht mehr unterstützt.Es wurde oft missverstanden. Falls Sie die Standardbibliothek ausschließen müssen, verwenden Sie --noLib or --libReplacement stattdessen solche, die die Absicht auf Konfigurationsebene deutlicher zum Ausdruck bringen.

Eine weitere, seit langem bestehende Quelle der Verwirrung ist, wie tsc behandelt explizite Dateiargumente, wenn ein tsconfig.json ist anwesendZuvor lief tsc foo.ts In einem solchen Verzeichnis würde die Konfigurationsdatei stillschweigend ignoriert. In Version 6.0 führt dieses Szenario zu einem expliziten Fehler:

error TS5112: tsconfig.json is present but will not be loaded if files are specified on commandline. Use '--ignoreConfig' to skip this error.

Wenn Sie die Konfiguration wirklich umgehen und einfach eine einzelne Datei mit Standardeinstellungen kompilieren möchten, können Sie jetzt verwenden tsc --ignoreConfig foo.ts um diese Absicht deutlich zu machen.

Vorbereitung auf TypeScript 7.0

TypeScript 6.0 ist funktionsvollständig und befindet sich größtenteils im Stabilisierungsmodus.Bis zur allgemeinen Verfügbarkeit erwartet das Team nur noch kritische Fehlerbehebungen. Regelmäßig werden Nightly Builds veröffentlicht, und das Team stellt außerdem Nightly-Versionen des kommenden nativen (Go-basierten) TypeScript 7.0 sowie eine spezielle VS Code-Erweiterung zum Experimentieren mit der neuen Engine bereit.

Der Fahrplan ist bewusst straff gehalten: Version 7.0 wird voraussichtlich kurz nach Version 6.0 erscheinen.Dadurch wird der Feedback-Zyklus bezüglich Upgrade-Problemen und Migrationsschwierigkeiten kurz sein. Wenn Sie in Version 6.0 Warnungen zu veralteten Funktionen sehen, wird dringend empfohlen, diese jetzt zu beheben, anstatt zu warten, bis Version 7.0 das Problem unumgänglich macht.

Der praktische Arbeitsablauf für die meisten Teams sieht folgendermaßen aus:Aktualisieren Sie auf TypeScript 6.0 RC, beheben Sie Ihr Problem. types , rootDir, Adressänderungen (oder diese vorübergehend hinter einer Sperre verbergen) "ignoreDeprecations": "6.0" während Sie iterieren), und führen Sie mit --stableTypeOrdering Wenn Sie Ausgaben vergleichen oder CI-Pipelines für die deterministische Reihenfolge von Version 7.0 vorbereiten müssen, ist dies erforderlich. Sobald dies eingerichtet ist, sollte sich der Wechsel zum Go-basierten Compiler eher wie eine Leistungsverbesserung als wie eine grundlegende Neuentwicklung anfühlen.

Zusammenfassend lässt sich sagen, dass es bei TypeScript 6.0 RC weniger um eine ansprechende Syntax geht, sondern vielmehr um die Schaffung der Voraussetzungen.Native Geschwindigkeit in Version 7.0, übersichtlichere Konfigurationen, moderne Standardeinstellungen und standardisierte APIs wie Temporal und die integrierten ES2025-Funktionen erleichtern die tägliche Programmierung. Wenn Sie jetzt einsteigen, die problematischen Stellen beheben und die neuen Standardeinstellungen nutzen, sind Sie deutlich besser gerüstet, sobald der native Compiler verfügbar ist.