Flexiblere Platzierung von Rest-Elementen in Tupeln und mehr: Das ist neu in TypeScript 4.2
TypeScript erfreut sich steigender Beliebtheit. (Foto: Joyseulay / shutterstock)
TypeScript, das JavaScript-Derivat aus dem Hause Microsoft, hat mit Version 4.2 ein Update erhalten – und bringt neben einigen wenigen Breaking Changes auch spannende Neuerungen mit.
Mehr Flexibilität für Rest-Elemente in Tupeln
Ursprünglich wurden Tuple-Typen in TypeScript eingeführt, um Arrays von einer bestimmten Länge und mit bestimmten Elementtypen zu modellieren. Seit einiger Zeit kommen sie auch bei Modellierung von Parameter-Listen in JS zum Einsatz und verfügen über optionale Elemente und Rest-Elemente sowie über Tooling- und Readability-Label. Ähnlich wie Rest-Parameter in JS stehen TypeScripts Rest-Elemente für eine beliebige Anzahl von Elementen. In TypeScript 4.2 wurden Tuple nun so überarbeitet, dass Rest-Elemente statt nur am Ende eines Tupels auch mittig oder am Anfang platziert werden können. Einzige Einschränkung: Pro Tupel darf maximal ein Rest-Element vorkommen, dem zudem keine weiteren optionalen Elemente folgen dürfen. Strukturen wie
interface Clown { /*...*/ }
interface Joker { /*...*/ }
let StealersWheel: [...Clown[], "me", ...Joker[]];
// ~~~~~~~~~~ Error!
// A rest element cannot follow another rest element.
und
let StringsAndMaybeBoolean: [...string[], boolean?];
// ~~~~~~~~ Error!
// An optional element cannot follow a rest element.sind demnach nicht möglich.
Verbesserte Type Alias Preservation
Aliase werden in TypeScript nach einem allgemeingültigen Regelwerk angezeigt – vor allem im Zusammenhang mit Code-Editoren wie Visual Studio Code war das oft problembehaftet. Hovern wir im folgenden Code-Snippet in VS Code mit der Maus über t3n, informiert ein Info-Panel darüber, dass es sich dabei um eine Entität vom Typ BasicPrimitive
handelt.
export type BasicPrimitive = number | string | boolean;
export function doStuff(value: BasicPrimitive) {
let t3n = value;
return t3n;
}
Wenn anstelle der Variable t3n ein
BasicPrimitive oder undefined zurückgegeben werden soll, zeigt TypeScript anstelle des erwarteten Return-Types BasicPrimitive oder undefined stattdessen string | number | boolean | undefined.
export type BasicPrimitive = number | string | boolean;
export function doStuff(value: BasicPrimitive) {
if (Math.random() < 0.5) {
return undefined;
}
return value;
}
Der Grund ist eine Ungenauigkeit in TypeScripts internaler Typenrepräsentation, die mit TypeScript 4.2 jetzt behoben wurde. Das führt außerdem zu einem verbesserten .d.ts-Datei-Output sowie genaueren Fehlermeldungen und In-Editor-Type-Informationen. Wer sich im Detail für die Implementation interessiert, kann den ersten Pull-Request zum Feature zurate ziehen.
Striktere Checks für den in-Operator
Auch bei der korrekten Verwendung des in-Operators schaut der neueste Release der Programmiersprache genauer hin: Wer ihn fehlerhaft einsetzt – erlaubt ist er schließlich nur für Objekttypen und nicht für Primitive –, erhält mit TypeScript 4.2 eine entsprechende Warnung.
Die Projektstruktur besser verstehen: Neue –explainFiles Flag
Eine Frage, die sich TypeScript-User laut Blogpost zum Release häufig zu stellen scheinen, lautet: „Warum inkludiert TypeScript eine bestimmte Datei?“ Die neue --explainFiles-Flag hält Antworten bereit – wenn ihr bereit seid, euch durch den resultierenden umfangreichen Output des Compilers zu arbeiten.
Breaking Chances
Zwar hatte das Team hinter der Programmiersprache versucht, nicht abwärtskompatible Änderungen nach Möglichkeit gering zu halten, ganz ohne kommt der neue Release jedoch leider nicht aus. So erlaubt der in-Operator mit der neuen Version keine Primitive Types zu seiner Rechten und es gibt ein neues Größenlimit für Tuples mit Spread-Elementen.
Alle Details zu weiteren Neuerungen, wie die Möglichkeit abstrakter Konstrukte oder eine weitere Flag namens --noPropertyAccessFromIndexSignature und natürlich alle Breaking Changes, die ihr bei einem Upgrade im Auge behalten solltet, könnt ihr im Blogpost zum Release nachlesen.
