Améliorations des performances de --build, --watch et --incremental TypeScript 4.8 introduit plusieurs optimisations qui devraient accélérer les scénarios autour de --watch et --incremental, ainsi que les constructions de références de projet à l'aide de --build. Par exemple, TypeScript est désormais en mesure d'éviter de passer du temps à mettre à jour les horodatages pendant les modifications sans opération en mode --watch, ce qui accélère les reconstructions et évite de déranger les autres outils de construction qui pourraient surveiller la sortie de TypeScript. De nombreuses autres optimisations permettant de réutiliser les informations dans --build, --watch et --incremental ont également été introduites.
Quelle est l'ampleur de ces améliorations*? Eh bien, sur une base de code interne assez importante, l'équipe TypeScript a constaté des réductions de temps de l'ordre de 10*% à 25*% sur de nombreuses opérations courantes simples, avec des réductions de temps d'environ 40*% dans des scénarios sans changement. L'équipe a également constaté des résultats similaires sur la base de code TypeScript.
Erreurs lors de la comparaison des littéraux d'objet et de tableau
Dans de nombreux langages, les opérateurs comme == effectuent ce qu'on appelle l'égalité de « valeur » sur les objets. Par exemple, en Python, il est valide de vérifier si une liste est vide en vérifiant si une valeur est égale à la liste vide en utilisant ==.
| Code Python : | Sélectionner tout |
1 2 | if people_at_home == []: print("that's where she lies, broken inside. </3") |
Ce n'est pas le cas en JavaScript, où == et === entre les objets et les tableaux vérifient si les deux références pointent vers la même instance. L'équipe TypeScript pense qu'il s'agit au mieux d'une première amorce pour les développeurs JavaScript, et au pire d'un bogue dans le code de production. C'est pourquoi TypeScript interdit désormais le code comme celui-ci.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 | let peopleAtHome = []; if (peopleAtHome === []) { // ~~~~~~~~~~~~~~~~~~~ // This condition will always return 'false' since JavaScript compares objects by reference, not value. console.log("that's where she lies, broken inside. </3") } |
Inférence améliorée à partir de modèles de liaison
Dans certains cas, TypeScript sélectionnera un type à partir d'un modèle de liaison pour faire de meilleures inférences.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 | declare function chooseRandomly<T>(x: T, y: T): T; let [a, b, c] = chooseRandomly([42, true, "hi!"], [0, false, "bye!"]); // ^ ^ ^ // | | | // | | string // | | // | boolean // | // number |
Lorsque chooseRandomly a besoin de trouver un type pour T, il regardera principalement [42, true, "hi!"] et [0, false, "bye!"]*; mais TypeScript doit déterminer si ces deux types doivent être Array<number | boolean | string> ou le type de tuple [number, boolean, string]. Pour ce faire, il recherchera les candidats existants comme un indice pour voir s'il existe des types de tuples. Lorsque TypeScript voit le modèle de liaison [a, b, c], il crée le type [any, any, any], et ce type est sélectionné comme candidat de faible priorité pour T qui est également utilisé comme indice pour les types de [42, true, "hi!"] et [0, false, "bye!"].
Vous pouvez voir à quel point cela était bon pour chooseRandomly, mais cela a échoué dans d'autres cas. Par exemple, prenez le code suivant
| Code TypeScript : | Sélectionner tout |
1 2 3 | declare function f<T>(x?: T): T; let [x, y, z] = f(); |
Le motif de liaison [x, y, z] indiquait que f devrait produire un tuple [any, any, any]*; mais f ne devrait vraiment pas changer son argument de type en fonction d'un modèle de liaison. Il ne peut pas soudainement évoquer une nouvelle valeur de type tableau en fonction de ce à quoi il est assigné, de sorte que le type de modèle de liaison a beaucoup trop d'influence sur le type produit. En plus de cela, parce que le type de modèle de liaison est plein de any, nous nous retrouvons avec x, y et z tapés comme any.
Dans TypeScript 4.8, ces modèles de liaison ne sont jamais utilisés comme candidats pour les arguments de type. Au lieu de cela, ils sont simplement consultés au cas où un paramètre nécessiterait un type plus spécifique, comme dans notre exemple chooseRandomly. Si vous devez revenir à l'ancien comportement, vous pouvez toujours fournir des arguments de type explicites.
Inférence améliorée pour les types d'inférence dans les types de chaîne de template
TypeScript a récemment introduit un moyen d'ajouter des contraintes d'extension pour déduire des variables de type dans des types conditionnels.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 | // Grabs the first element of a tuple if it's assignable to 'number', // and returns 'never' if it can't find one. type TryGetNumberIfFirst<T> = T extends [infer U extends number, ...unknown[]] ? U : never; |
Si ces types d'inférence apparaissent dans un type de chaîne de template et sont contraints à un type primitif, TypeScript essaiera maintenant d'analyser un type littéral.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 | // SomeNum used to be 'number'; now it's '100'. type SomeNum = "100" extends `${infer U extends number}` ? U : never; // SomeBigInt used to be 'bigint'; now it's '100n'. type SomeBigInt = "100" extends `${infer U extends bigint}` ? U : never; // SomeBool used to be 'boolean'; now it's 'true'. type SomeBool = "true" extends `${infer U extends boolean}` ? U : never; |
Cela peut maintenant mieux transmettre ce qu'une bibliothèque fera au moment de l'exécution et donner des types plus précis.
Une note à ce sujet est que lorsque TypeScript analyse ces types littéraux, il essaiera avidement d'analyser autant de ce qui ressemble au type primitif approprié; cependant, il vérifie ensuite si la réimpression de cette primitive correspond au contenu de la chaîne. En d'autres termes, TypeScript vérifie si le passage de la chaîne à la primitive et le retour correspondent. Si ce n'est pas le cas, alors il reviendra au type primitif de base.
| Code TypeScript : | Sélectionner tout |
1 2 | // JustNumber is `number` here because TypeScript parses out `"1.0"`, but `String(Number("1.0"))` is `"1"` and doesn't match. type JustNumber = "1.0" extends `${infer T extends number}` ? T : never; |
Amélioration de la réduction des intersections et de la compatibilité des unions
TypeScript 4.8 apporte une série d'améliorations d'exactitude et de cohérence sous --strictNullChecks. Ces changements affectent le fonctionnement des types d'intersection...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.