1 pièce(s) jointe(s)
Microsoft annonce la disponibilité de TypeScript 3.5 qui apporte une amélioration de la vitesse
Microsoft annonce la disponibilité de TypeScript 3.5 qui apporte une amélioration de la vitesse,
et de nombreuses optimisations
TypeScript est un langage qui repose sur JavaScript et qui ajoute des types statiques facultatifs. Le code TypeScript est soumis à une vérification de type pour éviter les erreurs courantes telles que les fautes de frappe et les coercitions accidentelles, puis il est transformé par le compilateur TypeScript. Le compilateur supprime toute syntaxe spécifique à TypeScript et transforme éventuellement votre code pour qu'il fonctionne avec les navigateurs plus anciens, vous laissant ainsi un code JavaScript propre et lisible qui peut s'exécuter dans votre navigateur préféré ou dans Node.js. Au-dessus de tout cela, il existe également un service de langage qui utilise toutes les informations de type que TypeScript doit fournir à des fonctionnalités d'édition puissantes telles que la complétion de code, les références de recherche globale, les solutions rapides et les refactorings. Tout cela est multi-plateforme, multi-éditeur et open source.
TypeScript fournit également le même outil aux utilisateurs de JavaScript et peut même vérifier le code JavaScript saisi avec JSDoc à l'aide de l'indicateur checkJs. Si vous avez utilisé des éditeurs tels que Visual Studio ou Visual Studio Code avec des fichiers .js, TypeScript vous permet de le faire, de sorte que vous utilisez peut-être déjà TypeScript!
Amélioration de la vitesse
TypeScript 3.5 introduit plusieurs optimisations.
Vérification de type
Une grande partie de l'expressivité du système de types a un coût - toute tâche supplémentaire attendue du compilateur se traduira par des temps de compilation plus longs. Malheureusement, dans le cadre d'une correction de bogue dans TypeScript 3.4, Microsoft a accidentellement introduit une régression qui pourrait entraîner une explosion du travail effectué par le vérificateur de type et, à son tour, du temps de vérification du type. Cette régression était grave, non seulement parce qu'elle entraînait des temps de build beaucoup plus longs pour le code TypeScript, mais aussi parce que les opérations d'édition pour les utilisateurs de TypeScript et de JavaScript étaient devenues trop lentes.
Au cours de la dernière version, Microsoft s’est concentré sur l'optimisation de certains chemins de code et la suppression de certaines fonctionnalités au point que TypeScript 3.5 est en réalité plus rapide que TypeScript 3.3 pour de nombreuses vérifications incrémentielles. Non seulement les temps de compilation ont-ils diminué par rapport à 3.4, mais la complétion du code et toutes les autres opérations de l'éditeur devraient également être beaucoup plus rapides.
améliorations --incremental
TypeScript 3.4 a introduit une nouvelle option compilateur --incremental. Cette option enregistre de nombreuses informations dans un fichier .tsbuildinfo, qui peut être utilisé pour accélérer les prochains appels à tsc.
TypeScript 3.5 inclut plusieurs optimisations pour la mise en cache. Dans des scénarios impliquant des centaines de projets utilisant les références de projet TypeScript en mode --build, Microsoft a constaté que le temps nécessaire à une rebuild peut être réduit de 68% par rapport à TypeScript 3.4.
Le type d'assistance Omit
La plupart du temps, nous voulons créer un objet qui omet certaines propriétés. Il s’avère que nous pouvons exprimer de tels types comme ceux qui utilisent les aides intégrées à TypeScript Pick et Exclude. Par exemple, si nous voulions définir une Person qui n’a pas de propriété location, nous pourrions écrire ce qui suit:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| type Person = {
name: string;
age: number;
location: string;
};
type RemainingKeys = Exclude<keyof Person, "location">;
type QuantumPerson = Pick<Person, RemainingKeys>;
// equivalent to
type QuantumPerson = {
name: string;
age: number;
}; |
Ici, nous avons "soustrait" "location" de l'ensemble des propriétés de Person à l'aide du type d'assistance Exclude. Nous les avons ensuite sélectionnés directement auprès de Person en utilisant le type d’assistant Pick.
Il s'avère que ce type d'opération est assez fréquent pour que les utilisateurs écrivent un type d'assistance pour faire exactement cela:
Code:
type Omit<T, K extends keyof any> = Pick<T, Exclude<keyof T, K>>;
Au lieu de laisser chacun définir sa propre version d'Omit, TypeScript 3.5 inclura sa propre version dans lib.d.ts, qui peut être utilisée n'importe où. Le compilateur lui-même utilisera ce type Omit pour exprimer des types créés via des déclarations de déstructuration d'objet sur des génériques.
Amélioration des contrôles de propriété excédentaire dans les types d'union
TypeScript a une fonctionnalité appelée excess property checking qui vérifie les littéraux d'objet. Cette fonctionnalité est destinée à détecter les fautes de frappe lorsqu'un type n'attend pas une propriété spécifique.
Code:
1
2
3
4
5
6
7
8
9
10
| type Style = {
alignment: string,
color?: string
};
const s: Style = {
alignment: "center",
colour: "grey"
// ^^^^^^ error!
}; |
Dans TypeScript 3.4 et les versions antérieures, certaines propriétés excessives étaient autorisées dans des situations où elles n’auraient pas dû l’être. Par exemple, TypeScript 3.4 autorisait la propriété incorrecte name dans le littéral d'objet même si ses types ne correspondent pas entre Point et Label.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| type Point = {
x: number;
y: number;
};
type Label = {
name: string;
};
const thing: Point | Label = {
x: 0,
y: 0,
name: true // uh-oh!
}; |
Auparavant, une union non discriminée ne subissait aucune vérification de propriété excédentaire sur ses membres et, par conséquent, la propriété name mal typée glissait entre les mailles.
Dans TypeScript 3.5, le vérificateur de type vérifie au moins que toutes les propriétés fournies appartiennent à un membre de l'union et ont le type approprié, ce qui signifie que l'exemple ci-dessus génère correctement une erreur.
Notez que le chevauchement partiel est toujours autorisé tant que les types de propriété sont valides.
Code:
1
2
3
4
5
| const pl: Point | Label = {
x: 0,
y: 0,
name: "origin" // okay
}; |
Le drapeau --allowUmdGlobalAccess
Dans TypeScript 3.5, vous pouvez maintenant référencer des déclarations globales UMD telles que
Code:
export as namespace foo;
de n'importe où - même des modules - en utilisant le nouvel indicateur --allowUmdGlobalAccess.
Vérification plus intelligente du type d'union
Lors de la vérification des types d'union, TypeScript compare généralement chaque type de constituant de manière isolée. Par exemple, prenons le code suivant:
Code:
1
2
3
4
5
6
7
8
9
| type S = { done: boolean, value: number }
type T =
| { done: false, value: number }
| { done: true, value: number };
declare let source: S;
declare let target: T;
target = source; |
L'affectation de source à target implique de vérifier si le type de source est assignable à target. Cela signifie que TypeScript doit vérifier si S
{ done: boolean, value: number }est assignable à T
{ done: false, value: number } | { done: true, value: number }Avant TypeScript 3.5, la vérification de cet exemple spécifique échouait, car S n’est pas assignable à { done: false, value: number } ni à { done: true, value: number }. Pourquoi? Parce que la propriété done dans S n’est pas assez spécifique, c’est une valeur booléenne alors que chaque composant de T a une propriété done spécifiquement vraie ou fausse. C’est ce que Microsoft voulait dire par vérification individuelle de chaque type de composant: TypeScript ne fait pas que réunir chaque propriété et voir si S est assignable à cette propriété. Si tel était le cas, un code incorrect pourrait passer comme ceci:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
interface Foo {
kind: "foo";
value: string;
}
interface Bar {
kind: "bar";
value: number;
}
function doSomething(x: Foo | Bar) {
if (x.kind === "foo") {
x.value.toLowerCase();
}
}
// uh-oh - luckily TypeScript errors here!
doSomething({
kind: "foo",
value: 123,
}); |
Il est donc clair que ce comportement convient à certains cas. TypeScript a-t-il été utile dans l'exemple d'origine? Pas vraiment. Si vous déterminez le type précis de toute valeur possible de S, vous constaterez qu’elle correspond exactement aux types de T.
C’est pourquoi, dans TypeScript 3.5, lors de l’attribution de types à propriétés discriminantes comme dans T, le langage ira plus loin et décomposera les types tels que S en une union de tous les types possibles. Dans ce cas, puisque boolean est une union de true et de false, S sera considéré comme une union de { done: false, value: number } et { done: true, value: number }.
Source : Microsoft
