2 pièce(s) jointe(s)
Microsoft annonce la disponibilité de TypeScript 5.3
Microsoft annonce la disponibilité de TypeScript 5.3 Beta,
et présente une liste rapide des nouveautés de TypeScript 5.3 Beta
Pour commencer à utiliser la version bêta, vous pouvez l'obtenir via NuGet, ou via npm avec la commande suivante :
Code:
npm install -D typescript@beta
Voici une liste rapide des nouveautés de TypeScript 5.3 !
- Attributs d'importation
- Stable Support resolution-mode dans les types d'importation
- switch (true) Rétrécissement
- Rétrécissement sur les comparaisons avec les booléens
- instanceof Narrowing Through Symbol.hasInstance
- Vérifie les accès aux super propriétés sur les champs d'instance
- Indices d'incrustation interactifs pour les types
- Optimisations en sautant l'analyse JSDoc
- Optimisation par comparaison d'intersections non normalisées
- Consolidation entre tsserverlibrary.js et typescript.js
- Changements de rupture et améliorations de la correction
Attributs d'importation
TypeScript 5.3 prend en charge les dernières mises à jour de la proposition relative aux attributs d'importation.
L'un des cas d'utilisation des attributs d'importation est de fournir des informations sur le format attendu d'un module au moteur d'exécution.
Code:
1
2
3
| // We only want this to be interpreted as JSON,
// not a runnable/malicious JavaScript file with a `.json` extension.
import obj from "./something.json" with { type: "json" }; |
Le contenu de ces attributs n'est pas vérifié par TypeScript puisqu'ils sont spécifiques à l'hôte, et sont simplement laissés en l'état pour que les navigateurs et les moteurs d'exécution puissent les gérer (et éventuellement commettre des erreurs).
Code:
1
2
3
| // TypeScript is fine with this.
// But your browser? Probably not.
import * as foo from "./foo.js" with { type: "fluffy bunny" }; |
Les appels dynamic import() peuvent également utiliser des attributs d'importation par le biais d'un second argument.
Code:
1
2
3
| const obj = await import("./something.json", {
with: { type: "json" }
}); |
Le type attendu de ce second argument est défini par un type appelé ImportCallOptions, qui par défaut attend simplement une propriété appelée with.
Notez que les attributs d'importation sont une évolution d'une proposition antérieure appelée "assertions d'importation", qui a été mise en œuvre dans TypeScript 4.5. La différence la plus évidente est l'utilisation du mot-clé withau lieu du mot-clé assert. Mais la différence la moins visible est que les moteurs d'exécution sont désormais libres d'utiliser les attributs pour guider la résolution et l'interprétation des chemins d'importation, alors que les assertions d'importation ne pouvaient affirmer certaines caractéristiques qu'après le chargement d'un module.
Au fil du temps, TypeScript abandonnera l'ancienne syntaxe des assertions d'importation au profit de la syntaxe proposée pour les attributs d'importation. Le code existant utilisant assertdevrait migrer vers le mot-clé with. Le nouveau code qui a besoin d'un attribut d'importation devrait utiliser exclusivement with.
Prise en charge stable du résolution-modedans les types d'importation
Dans TypeScript 4.7, TypeScript a ajouté le support d'un attribut resolution-modedans /// <reference types="..." /> pour contrôler si un spécificateur doit être résolu via importou requiresémantics.
Code:
1
2
3
4
5
| /// <reference types="pkg" resolution-mode="require" />
// or
/// <reference types="pkg" resolution-mode="import" /> |
Un champ correspondant a également été ajouté aux assertions d'importation sur les importations de type uniquement ; cependant, il n'a été pris en charge que dans les versions nocturnes de TypeScript. Le raisonnement était que, dans l'esprit, les assertions d'importation n'étaient pas destinées à guider la résolution des modules. Cette fonctionnalité a donc été livrée à titre expérimental en mode "nightly only" afin d'obtenir davantage de retours.
Mais étant donné que les attributs d'importation peuvent guider la résolution, et que nous avons vu des cas d'utilisation raisonnables, TypeScript 5.3 supporte maintenant l'attribut resolution-modepour le import type.
Code:
1
2
3
4
5
6
7
8
9
10
11
| // Resolve `pkg` as if we were importing with a `require()`
import type { TypeFromRequire } from "pkg" with {
"resolution-mode": "require"
};
// Resolve `pkg` as if we were importing with an `import`
import type { TypeFromImport } from "pkg" with {
"resolution-mode": "import"
};
export interface MergedType extends TypeFromRequire, TypeFromImport {} |
Ces attributs d'importation peuvent également être utilisés pour les import() types.
Code:
1
2
3
4
5
6
7
| export type TypeFromRequire =
import("pkg", { with: { "resolution-mode": "require" } }).TypeFromRequire;
export type TypeFromImport =
import("pkg", { with: { "resolution-mode": "import" } }).TypeFromImport;
export interface MergedType extends TypeFromRequire, TypeFromImport {} |
Rétrécissement du switch (true)
TypeScript 5.3 peut désormais effectuer un rétrécissement basé sur des conditions dans chaque case clause à l'intérieur switch (true).
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| function f(x: unknown) {
switch (true) {
case typeof x === "string":
// 'x' is a 'string' here
console.log(x.toUpperCase());
// falls through...
case Array.isArray(x):
// 'x' is a 'string | any[]' here.
console.log(x.length);
// falls through...
default:
// 'x' is 'unknown' here.
// ...
}
} |
Limiter les comparaisons aux booléens
Il peut arriver que vous ayez à effectuer une comparaison directe avec trueou falsedans une condition. Il s'agit généralement de comparaisons inutiles, mais vous pouvez les préférer pour des raisons de style ou pour éviter certains problèmes liés à la véracité de JavaScript. Quoi qu'il en soit, TypeScript ne reconnaissait pas ces formes lorsqu'il effectuait un rétrécissement.
TypeScript 5.3 se met désormais au diapason et comprend ces expressions lors du rétrécissement des variables.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| interface A {
a: string;
}
interface B {
b: string;
}
type MyType = A | B;
function isA(x: MyType): x is A {
return "a" in x;
}
function someFn(x: MyType) {
if (isA(x) === true) {
console.log(x.a); // works!
}
} |
instanceof Narrowing Through Symbol.hasInstance
Une caractéristique légèrement ésotérique de JavaScript est qu'il est possible d'outrepasser le comportement de l'opérateur instanceof. Pour ce faire, la valeur à droite de l'opérateur instanceofdoit avoir une méthode spécifique nommée par Symbol.hasInstance.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
| class Weirdo {
static [Symbol.hasInstance](testedValue) {
// wait, what?
return testedValue === undefined;
}
}
// false
console.log(new Thing() instanceof Weirdo);
// true
console.log(undefined instanceof Weirdo); |
Pour mieux modéliser ce comportement dans instanceof, TypeScript vérifie maintenant si une telle méthode [Symbol.hasInstance] existe et est déclarée comme une fonction de prédicat de type. Si c'est le cas, la valeur testée à gauche de l'opérateur instanceofsera restreinte de manière appropriée par ce prédicat de type.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
| interface PointLike {
x: number;
y: number;
}
class Point implements PointLike {
x: number;
y: number;
constructor(x: number, y: number) {
this.x = x;
this.y = y;
}
distanceFromOrigin() {
return Math.sqrt(this.x ** 2 + this.y ** 2);
}
static [Symbol.hasInstance](val: unknown): val is PointLike {
return !!val && typeof val === "object" &&
"x" in val && "y" in val &&
typeof val.x === "number" &&
typeof val.y === "number";
}
}
function f(value: unknown) {
if (value instanceof Point) {
// Can access both of these - correct!
value.x;
value.y;
// Can't access this - we have a 'PointLike',
// but we don't *actually* have a 'Point'.
value.distanceFromOrigin();
}
} |
Comme vous pouvez le voir dans cet exemple, Pointdéfinit sa propre méthode [Symbol.hasInstance]. Elle agit en fait comme une protection de type personnalisée sur un type distinct appelé PointLike. Dans la fonction f, Microsoft a pu réduire la valeurà un PointLikeavec instanceof, mais pas à un Point. Cela signifie que nous pouvons accéder aux propriétés xet y, mais pas à la méthode distanceFromOrigin.
Vérification des accès à la propriété supersur les champs d'instance
En JavaScript, il est possible d'accéder à une déclaration dans une classe de base grâce au mot-clé super.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| class Base {
someMethod() {
console.log("Base method called!");
}
}
class Derived extends Base {
someMethod() {
console.log("Derived method called!");
super.someMethod();
}
}
new Derived().someMethod();
// Prints:
// Derived method called!
// Base method called! |
Cela diffère de l'écriture de quelque chose comme this.someMethod(), puisque cela pourrait invoquer une méthode surchargée. Il s'agit d'une distinction subtile, rendue encore plus subtile par le fait que les deux peuvent souvent être interchangeables si une déclaration n'est jamais surchargée.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| class Base {
someMethod() {
console.log("someMethod called!");
}
}
class Derived extends Base {
someOtherMethod() {
// These act identically.
this.someMethod();
super.someMethod();
}
}
new Derived().someOtherMethod();
// Prints:
// someMethod called!
// someMethod called! |
Le problème de leur utilisation interchangeable est que super ne fonctionne que sur les membres déclarés dans le prototype - et non sur les propriétés de l'instance. Cela signifie que si vous écrivez super.someMethod(), mais que someMethodest défini comme un champ, vous obtiendrez une erreur d'exécution !
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| class Base {
someMethod = () => {
console.log("someMethod called!");
}
}
class Derived extends Base {
someOtherMethod() {
super.someMethod();
}
}
new Derived().someOtherMethod();
// 💥
// Doesn't work because 'super.someMethod' is 'undefined'. |
TypeScript 5.3 inspecte désormais de plus près les accès aux superpropriétés et les appels de méthodes pour voir s'ils correspondent à des champs de classe. Si c'est le cas, Microsoft obtiendrons désormais une erreur de vérification de type.
Indices d'incrustation interactifs pour les types
Les indices d'incrustation de TypeScript permettent désormais de sauter à la définition des types ! Cela facilite la navigation dans votre code.
Lors de l'exécution de TypeScript via tsc, le compilateur évitera désormais d'analyser JSDoc. Cela réduit le temps d'analyse en soi, mais réduit également l'utilisation de la mémoire pour stocker les commentaires ainsi que le temps passé dans le garbage collection. Dans l'ensemble, vous devriez voir des compilations légèrement plus rapides et un retour d'information plus rapide en mode --watch.
Parce que tous les outils utilisant TypeScript n'auront pas besoin de stocker JSDoc (par exemple, typescript-eslint et Prettier), cette stratégie d'analyse a été présentée comme faisant partie de l'API elle-même. Cela peut permettre à ces outils de bénéficier des mêmes améliorations en termes de mémoire et de vitesse que celles que Microsoft a apportées au compilateur TypeScript. Les nouvelles options pour la stratégie d'analyse des commentaires sont décrites dans JSDocParsingMode.
Optimisations par comparaison d'intersections non normalisées
En TypeScript, les unions et les intersections suivent toujours une forme spécifique, où les intersections ne peuvent pas contenir de types d'union. Cela signifie que lorsque nous créons une intersection sur une union comme A & (B | C), cette intersection sera normalisée en (A & B) | (A & C). Cependant, dans certains cas, le système de types conservera la forme originale à des fins d'affichage.
Il s'avère que la forme originale peut être utilisée pour des comparaisons rapides et astucieuses entre les types.
Par exemple, disons que nous avons un someType & (Type1 | Type2 | ... | Type99999NINE) et que nous voulons voir s'il est assignable à un someType. Rappelons que nous n'avons pas vraiment d'intersection comme type source - nous avons une union qui ressemble à (UnType & Type1) | (UnType & Type2) | ... ... |(UnType & Type99999NINE). Lorsqu'on vérifie si une union est assignable à un type cible, on doit vérifier si chaque membre de l'union est assignable au type cible, ce qui peut être très lent.
Consolidation entre tsserverlibrary.jset typescript.js
TypeScript est livré avec deux fichiers de bibliothèque : tsserverlibrary.js et typescript.js. Certaines API ne sont disponibles que dans tsserverlibrary.js (comme l'API ProjectService), ce qui peut être utile à certains importateurs. Cependant, les deux paquets sont distincts et se chevauchent beaucoup, dupliquant le code dans le paquet. De plus, il peut être difficile d'utiliser systématiquement l'un plutôt que l'autre en raison des importations automatiques ou de la mémoire musculaire. Il est beaucoup trop facile de charger accidentellement les deux modules, et le code peut ne pas fonctionner correctement sur une instance différente de l'API. Même s'il fonctionne, le chargement d'un second bundle augmente l'utilisation des ressources.
Dans ces conditions, Microsoft a décidé de consolider les deux modules. typescript.jscontient maintenant ce que tsserverlibrary.js contenait auparavant, et tsserverlibrary.jsré-exporte simplement typescript.js. En comparant l'avant/après de cette consolidation, Microsoft a constaté la réduction suivante de la taille des paquets :
En d'autres termes, il s'agit d'une réduction de plus de 20,5 % de la taille de l'emballage.
Changements de rupture et améliorations de la correction
Changements dans lib.d.tsLes types générés pour le DOM peuvent avoir un impact sur votre base de code.
Vérification des superaccès aux propriétés d'instance
TypeScript 5.3 détecte maintenant quand la déclaration référencée par un accès à la propriété super. est un champ de classe et émet une erreur. Cela permet d'éviter les erreurs qui pourraient survenir lors de l'exécution.
Quelles sont les prochaines étapes ?
À ce stade, TypeScript 5.3 est ce que Microsoft appelle "stable en termes de fonctionnalités". TypeScript 5.3 se concentrera sur les corrections de bogues, le polissage et certaines fonctionnalités d'édition à faible risque. Une version candidate sera disponible dans un peu plus d'un mois, suivie d'une version stable peu après.
Source : Microsoft
Et vous ?
:fleche: Quel est votre avis sur le sujet ?
:fleche: Quelles sont les fonctionnalités que vous aimeriez retrouver dans la prochaine version de Typescript ?
:fleche: Que pensez-vous des fonctionnalités proposées par cette version de TypeScript ?
Voir aussi :
:fleche: Microsoft annonce la Release Candidate de TypeScript 5.2 et présente une liste rapide des nouveautés de TypeScript 5.2
:fleche: Microsoft annonce la sortie de la version bêta de TypeScript 5.0, et apporte un nouveau standard pour les décorateurs en plus de nombreuses autres améliorations
2 pièce(s) jointe(s)
Microsoft annonce la disponibilité de TypeScript 5.3 Release Candidate
Microsoft annonce la disponibilité de TypeScript 5.3 Release Candidate, doucumentant le resolution-mode et ajoutant une option de préférence pour l'importation automatique des Type.
Microsoft annonce la Release Candidate de TypeScript 5.3 ! D'ici la sortie de la version stable de TypeScript 5.3, ils ne prévoient pas d'autres changements que des corrections de bugs critiques.
Pour commencer à utiliser la RC, vous pouvez l'obtenir via NuGet, ou via npm avec la commande suivante :
Code:
npm install -D typescript@rc
Voici une liste rapide des nouveautés de TypeScript 5.3 :
- Attributs d'importation
- Stable Support resolution-mode dans les types d'importation
- resolution-mode Pris en charge dans tous les modes du module
- switch (true) Rétrécissement
- Réduction sur les comparaisons avec les booléens
- instanceof Narrowing Through Symbol.hasInstance
- Vérifie les accès aux super propriétés sur les champs d'instance
- Incrustations interactives pour les types
- Paramètres pour préférer les importations automatiques de type
- Optimisations en sautant l'analyse JSDoc
- Optimisation par comparaison des intersections non normalisées
- Consolidation entre tsserverlibrary.js et typescript.js
- Changements de rupture et améliorations de la correction
Attributs d'importation
TypeScript 5.3 prend en charge les dernières mises à jour de la proposition relative aux attributs d'importation.
L'un des cas d'utilisation des attributs d'importation est de fournir des informations sur le format attendu d'un module au moteur d'exécution.
Code:
1
2
3
| // We only want this to be interpreted as JSON,
// not a runnable/malicious JavaScript file with a `.json` extension.
import obj from "./something.json" with { type: "json" }; |
Le contenu de ces attributs n'est pas vérifié par TypeScript puisqu'ils sont spécifiques à l'hôte, et sont simplement laissés tels quels afin que les navigateurs et les runtimes puissent les gérer (et éventuellement commettre des erreurs).
Code:
1
2
3
| // TypeScript is fine with this.
// But your browser? Probably not.
import * as foo from "./foo.js" with { type: "fluffy bunny" }; |
Les appels dynamiques import() peuvent également utiliser les attributs d'importation par le biais d'un second argument.
Code:
1
2
3
| const obj = await import("./something.json", {
with: { type: "json" }
}); |
Le type attendu de ce second argument est défini par un type appelé ImportCallOptions, qui par défaut attend simplement une propriété appelée with.
Notez que les attributs d'importation sont une évolution d'une proposition antérieure appelée "assertions d'importation", qui a été mise en œuvre dans TypeScript 4.5. La différence la plus évidente est l'utilisation du mot-clé with au lieu du mot-clé assert. Mais la différence la moins visible est que les moteurs d'exécution sont désormais libres d'utiliser les attributs pour guider la résolution et l'interprétation des chemins d'importation, alors que les assertions d'importation ne pouvaient affirmer certaines caractéristiques qu'après le chargement d'un module.
Au fil du temps, TypeScript abandonnera l'ancienne syntaxe des assertions d'importation au profit de la syntaxe proposée pour les attributs d'importation. Le code existant utilisant assert devrait migrer vers le mot-clé with. Le nouveau code qui a besoin d'un attribut d'importation devrait utiliser exclusivement le mot-clé with.
Stable Support resolution-mode dans les types d'importation
Dans TypeScript 4.7, TypeScript a ajouté la prise en charge d'un attribut resolution-mode dans /// <reference types="..." /> pour contrôler si un spécificateur doit être résolu via la sémantique import ou require.
Code:
1
2
3
4
5
| /// <reference types="pkg" resolution-mode="require" />
// or
/// <reference types="pkg" resolution-mode="import" /> |
Un champ correspondant a également été ajouté aux assertions d'importation sur les importations de type uniquement ; cependant, il n'a été pris en charge que dans les versions nocturnes de TypeScript. Le raisonnement était que, dans l'esprit, les assertions d'importation n'étaient pas destinées à guider la résolution des modules. Cette fonctionnalité a donc été livrée à titre expérimental en mode "nightly only" afin d'obtenir davantage de retours.
Mais étant donné que les attributs d'importation peuvent guider la résolution, et que nous avons vu des cas d'utilisation raisonnables, TypeScript 5.3 supporte maintenant l'attribut resolution-mode pour import type.
Code:
1
2
3
4
5
6
7
8
9
10
11
| // Resolve `pkg` as if we were importing with a `require()`
import type { TypeFromRequire } from "pkg" with {
"resolution-mode": "require"
};
// Resolve `pkg` as if we were importing with an `import`
import type { TypeFromImport } from "pkg" with {
"resolution-mode": "import"
};
export interface MergedType extends TypeFromRequire, TypeFromImport {} |
Ces attributs d'importation peuvent également être utilisés sur les types import().
Code:
1
2
3
4
5
6
7
| export type TypeFromRequire =
import("pkg", { with: { "resolution-mode": "require" } }).TypeFromRequire;
export type TypeFromImport =
import("pkg", { with: { "resolution-mode": "import" } }).TypeFromImport;
export interface MergedType extends TypeFromRequire, TypeFromImport {} |
resolution-mode Pris en charge dans tous les modes du module
Auparavant, l'utilisation de resolution-mode n'était autorisée que pour les options moduleResolution node16 et nodenext. Pour faciliter la recherche de modules spécifiques à des fins de typage, resolution-mode fonctionne désormais de manière appropriée dans toutes les autres options moduleResolution telles que bundler, node10, et ne provoque tout simplement pas d'erreur sous classic.
switch (true) Rétrécissement
TypeScript 5.3 peut désormais effectuer un rétrécissement basé sur des conditions dans chaque clause case à l'intérieur d'un switch (true).
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| function f(x: unknown) {
switch (true) {
case typeof x === "string":
// 'x' is a 'string' here
console.log(x.toUpperCase());
// falls through...
case Array.isArray(x):
// 'x' is a 'string | any[]' here.
console.log(x.length);
// falls through...
default:
// 'x' is 'unknown' here.
// ...
}
} |
Réduction sur les comparaisons avec les booléens
De temps en temps, vous pouvez vous retrouver à effectuer une comparaison directe avec true ou false dans une condition. En général, ces comparaisons sont inutiles, mais vous pouvez les préférer pour des raisons de style, ou pour éviter certains problèmes liés à la véracité de JavaScript. Quoi qu'il en soit, TypeScript ne reconnaissait pas ces formes lorsqu'il effectuait un rétrécissement.
TypeScript 5.3 se met désormais au diapason et comprend ces expressions lors du rétrécissement des variables.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| interface A {
a: string;
}
interface B {
b: string;
}
type MyType = A | B;
function isA(x: MyType): x is A {
return "a" in x;
}
function someFn(x: MyType) {
if (isA(x) === true) {
console.log(x.a); // works!
}
} |
instanceof Narrowing Through Symbol.hasInstance
Une caractéristique légèrement ésotérique de JavaScript est qu'il est possible d'outrepasser le comportement de l'opérateur instanceof. Pour ce faire, la valeur à droite de l'opérateur instanceof doit avoir une méthode spécifique nommée par Symbol.hasInstance.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
| class Weirdo {
static [Symbol.hasInstance](testedValue) {
// wait, what?
return testedValue === undefined;
}
}
// false
console.log(new Thing() instanceof Weirdo);
// true
console.log(undefined instanceof Weirdo); |
Pour mieux modéliser ce comportement dans instanceof, TypeScript vérifie maintenant si une telle méthode [Symbol.hasInstance] existe et est déclarée comme une fonction de prédicat de type. Si c'est le cas, la valeur testée à gauche de l'opérateur instanceof sera restreinte de manière appropriée par ce prédicat de type.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
| interface PointLike {
x: number;
y: number;
}
class Point implements PointLike {
x: number;
y: number;
constructor(x: number, y: number) {
this.x = x;
this.y = y;
}
distanceFromOrigin() {
return Math.sqrt(this.x ** 2 + this.y ** 2);
}
static [Symbol.hasInstance](val: unknown): val is PointLike {
return !!val && typeof val === "object" &&
"x" in val && "y" in val &&
typeof val.x === "number" &&
typeof val.y === "number";
}
}
function f(value: unknown) {
if (value instanceof Point) {
// Can access both of these - correct!
value.x;
value.y;
// Can't access this - we have a 'PointLike',
// but we don't *actually* have a 'Point'.
value.distanceFromOrigin();
}
} |
Comme vous pouvez le voir dans cet exemple, Point définit sa propre méthode [Symbol.hasInstance]. Elle agit en fait comme une protection de type personnalisée sur un type distinct appelé PointLike. Dans la fonction f, nous avons pu réduire value à un PointLike avec instanceof, mais pas à un Point. Cela signifie que nous pouvons accéder aux propriétés x et y, mais pas à la méthode distanceFromOrigin.
Vérifie les accès aux super propriétés sur les champs d'instance
En JavaScript, il est possible d'accéder à une déclaration dans une classe de base grâce au mot-clé super.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| class Base {
someMethod() {
console.log("Base method called!");
}
}
class Derived extends Base {
someMethod() {
console.log("Derived method called!");
super.someMethod();
}
}
new Derived().someMethod();
// Prints:
// Derived method called!
// Base method called! |
Ceci est différent d'écrire quelque chose comme this.someMethod(), puisque cela pourrait invoquer une méthode surchargée. Il s'agit d'une distinction subtile, rendue encore plus subtile par le fait que les deux peuvent souvent être interchangeables si une déclaration n'est jamais surchargée.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| class Base {
someMethod() {
console.log("someMethod called!");
}
}
class Derived extends Base {
someOtherMethod() {
// These act identically.
this.someMethod();
super.someMethod();
}
}
new Derived().someOtherMethod();
// Prints:
// someMethod called!
// someMethod called! |
Le problème de leur utilisation interchangeable est que super ne fonctionne que sur les membres déclarés dans le prototype - pas sur les propriétés d'instance. Cela signifie que si vous écrivez super.someMethod(), mais que someMethod est défini comme un champ, vous obtiendrez une erreur d'exécution !
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| class Base {
someMethod = () => {
console.log("someMethod called!");
}
}
class Derived extends Base {
someOtherMethod() {
super.someMethod();
}
}
new Derived().someOtherMethod();
// 💥
// Doesn't work because 'super.someMethod' is 'undefined'. |
TypeScript 5.3 inspecte désormais de plus près les accès à la propriété super et les appels de méthode pour voir s'ils correspondent à des champs de classe. Si c'est le cas, nous obtiendrons une erreur de vérification de type.
Incrustations interactives pour les types
Les indices d'incrustation de TypeScript permettent désormais de sauter à la définition des types ! Cela permet de naviguer plus facilement dans votre code.
Paramètres pour préférer les importations automatiques de types
Auparavant, lorsque TypeScript générait des auto-imports pour quelque chose dans une position de type, il ajoutait un modificateur de type basé sur vos paramètres. Par exemple, lors de l'obtention d'un auto-import sur Person dans l'exemple suivant :
Code:
export let p: Person
l'expérience d'édition de TypeScript ajoutait généralement un import pour Person en tant que :
Code:
1
2
3
| import { Person } from "./types";
export let p: Person |
et sous certains paramètres comme verbatimModuleSyntax, il ajouterait le modificateur de type :
Code:
1
2
3
| import { type Person } from "./types";
export let p: Person |
Cependant, il se peut que votre base de code ne soit pas en mesure d'utiliser certaines de ces options, ou que vous ayez simplement une préférence pour les importations de TYPE explicites lorsque c'est possible.
Grâce à un changement récent, TypeScript permet maintenant de faire de cette option une option spécifique à l'éditeur. Dans Visual Studio Code, vous pouvez l'activer dans l'interface utilisateur sous "TypeScript ' Preferences : Prefer Type Only Auto Imports", ou comme l'option de configuration JSON typescript.preferences.preferTypeOnlyAutoImportsOptimisations en sautant l'analyse JSDoc
Lors de l'exécution de TypeScript via tsc, le compilateur évitera désormais d'analyser JSDoc. Cela réduit le temps d'analyse en soi, mais réduit également l'utilisation de la mémoire pour stocker les commentaires ainsi que le temps passé dans le garbage collection. Dans l'ensemble, vous devriez voir des compilations légèrement plus rapides et un retour d'information plus rapide en mode --watch.
Parce que tous les outils utilisant TypeScript n'auront pas besoin de stocker JSDoc (par exemple, typescript-eslint et Prettier), cette stratégie d'analyse a été présentée comme faisant partie de l'API elle-même. Cela peut permettre à ces outils de bénéficier des mêmes améliorations en termes de mémoire et de vitesse que celles que nous avons apportées au compilateur TypeScript. Les nouvelles options pour la stratégie d'analyse des commentaires sont décrites dans JSDocParsingMode.
Optimisation par comparaison des intersections non normalisées
En TypeScript, les unions et les intersections suivent toujours une forme spécifique, où les intersections ne peuvent pas contenir de types d'union. Cela signifie que lorsque nous créons une intersection sur une union comme A & (B | C), cette intersection sera normalisée en (A & B) | (A & C). Cependant, dans certains cas, le système de types conservera la forme originale à des fins d'affichage.
Il s'avère que la forme originale peut être utilisée pour des comparaisons rapides et astucieuses entre les types.
Par exemple, disons que nous avons un SomeType & (Type1 | Type2 | ... | Type99999NINE) et que nous voulons voir s'il est assignable à un SomeType. Rappelons que nous n'avons pas vraiment d'intersection comme type source - nous avons une union qui ressemble à (SomeType & Type1) | (SomeType & Type2) | ... |(SomeType & Type99999NINE). Lorsqu'on vérifie si une union est assignable à un type cible, on doit vérifier si chaque membre de l'union est assignable au type cible, ce qui peut être très lent.
Dans TypeScript 5.3, nous jetons un coup d'œil à la forme d'intersection originale que nous avons pu mettre de côté. Lorsque nous comparons les types, nous vérifions rapidement si la cible existe dans l'un des constituants de l'intersection source.
Consolidation entre tsserverlibrary.js et typescript.js
TypeScript lui-même est livré avec deux fichiers de bibliothèque : tsserverlibrary.js et typescript.js. Certaines API ne sont disponibles que dans tsserverlibrary.js (comme l'API ProjectService), ce qui peut être utile à certains importateurs. Cependant, les deux paquets sont distincts et se chevauchent beaucoup, dupliquant le code dans le paquet. De plus, il peut être difficile d'utiliser systématiquement l'un plutôt que l'autre en raison des importations automatiques ou de la mémoire musculaire. Il est beaucoup trop facile de charger accidentellement les deux modules, et le code peut ne pas fonctionner correctement sur une instance différente de l'API. Même s'il fonctionne, le chargement d'un second bundle augmente l'utilisation des ressources.
Dans ces conditions, nous avons décidé de consolider les deux modules. typescript.js contient maintenant ce que tsserverlibrary.js contenait auparavant, et tsserverlibrary.js ré-exporte simplement typescript.js. En comparant l'avant/après de cette consolidation, nous avons constaté la réduction suivante de la taille des paquets :
En d'autres termes, il s'agit d'une réduction de plus de 20,5 % de la taille des paquets.
Changements de rupture et améliorations de la correction
Vérification des super-accès aux propriétés d'instance : TypeScript 5.3 détecte maintenant quand la déclaration référencée par un accès à la propriété super est un champ de classe et émet une erreur. Cela permet d'éviter les erreurs qui pourraient survenir lors de l'exécution.
Quelles sont les prochaines étapes ?
À ce stade, Microsoft ne prévoit pas de changements majeurs pour TypeScript 5.3. Au cours des deux prochaines semaines, ils chercheront à obtenir des commentaires, et ne prévoient d'introduire que des changements à faible risque pour les nouveaux comportements, et d'aborder les problèmes critiques.
Source : Microsoft
Et vous ?
:fleche: Quel est votre avis sur cette annonce ?
Voir aussi :
:fleche: Microsoft annonce la disponibilité de TypeScript 5.3 Beta Et présente une liste rapide des nouveautés de TypeScript 5.3 Beta
:fleche: Microsoft annonce la Release Candidate de TypeScript 5.2 Et présente une liste rapide des nouveautés de TypeScript 5.2
:fleche: Microsoft annonce la sortie de la version bêta de TypeScript 5.0 Et apporte un nouveau standard pour les décorateurs en plus de nombreuses autres améliorations
2 pièce(s) jointe(s)
Microsoft annonce la disponibilité de la version 5.3 de TypeScript
La version 5.3 de TypeScript est désormais disponible, et ajoute la prise en charge des attributs d'importation, ainsi qu'un support stable de resolution-mode dans les types d'importation
Aujourd'hui, Microsoft a le plaisir d'annoncer la sortie de TypeScript 5.3, la dernière version du langage de programmation libre et open source développé par Microsoft qui a pour but d'améliorer et de sécuriser la production de code JavaScript.
Si vous ne connaissez pas TypeScript, il s'agit d'un langage qui ajoute la syntaxe de type à JavaScript pour apporter la vérification de type. Le contrôle de type permet de détecter toutes sortes de problèmes, comme les fautes de frappe et l'oubli de la vérification de la présence de null et de undefined. Mais les types vont bien au-delà de la vérification de type - les mêmes analyses du vérificateur de type de TypeScript sont utilisées pour des outils d'édition riches comme l'auto-complétion, la navigation dans le code et les refactorisations. En fait, si vous avez écrit du JavaScript dans des éditeurs tels que Visual Studio ou VS Code, cette expérience est alimentée par TypeScript !
Pour commencer à utiliser TypeScript, vous pouvez l'obtenir via NuGet, ou via npm avec la commande suivante :
Code:
npm install -D typescript
Quelles sont les nouveautés depuis la bêta et la RC ?
Depuis la sortie de la version candidate, aucun changement majeur n'a eu lieu.
Depuis la sortie de la version bêta, une option a été ajoutée pour privilégier les auto-importations de type uniquement lorsque c'est possible.
La version bêta permettait d'utiliser le mode de résolution pour tous les paramètres de résolution des modules, mais ne le documentait pas.
Attributs d'importation
TypeScript 5.3 prend en charge les dernières mises à jour de la proposition relative aux attributs d'importation.
L'un des cas d'utilisation des attributs d'importation est de fournir des informations sur le format attendu d'un module au moteur d'exécution.
Code:
1
2
3
| // We only want this to be interpreted as JSON,
// not a runnable/malicious JavaScript file with a `.json` extension.
import obj from "./something.json" with { type: "json" }; |
Le contenu de ces attributs n'est pas vérifié par TypeScript car ils sont spécifiques à l'hôte, et sont simplement laissés tels quels afin que les navigateurs et les runtimes puissent les gérer (et éventuellement commettre des erreurs).
Code:
1
2
3
| // TypeScript is fine with this.
// But your browser? Probably not.
import * as foo from "./foo.js" with { type: "fluffy bunny" }; |
Les appels dynamiques import() peuvent également utiliser les attributs d'importation par le biais d'un second argument.
Code:
1
2
3
| const obj = await import("./something.json", {
with: { type: "json" }
}); |
Le type attendu de ce second argument est défini par un type appelé ImportCallOptions, qui par défaut attend simplement une propriété appelée with.
Notez que les attributs d'importation sont une évolution d'une proposition antérieure appelée "assertions d'importation", qui a été mise en œuvre dans TypeScript 4.5. La différence la plus évidente est l'utilisation du mot-clé with au lieu du mot-clé assert. Mais la différence la moins visible est que les moteurs d'exécution sont désormais libres d'utiliser les attributs pour guider la résolution et l'interprétation des chemins d'importation, alors que les assertions d'importation ne pouvaient affirmer certaines caractéristiques qu'après le chargement d'un module.
Au fil du temps, TypeScript abandonnera l'ancienne syntaxe des assertions d'importation au profit de la syntaxe proposée pour les attributs d'importation. Le code existant utilisant assert devrait migrer vers le mot-clé with. Le nouveau code qui a besoin d'un attribut d'importation devrait utiliser exclusivement with.
Support stable resolution-mode dans les types d'importation
Dans TypeScript 4.7, TypeScript a ajouté le support d'un attribut resolution-mode dans /// <reference types="..." /> pour contrôler si un spécificateur doit être résolu via la sémantique import ou require.
Code:
1
2
3
4
5
| /// <reference types="pkg" resolution-mode="require" />
// or
/// <reference types="pkg" resolution-mode="import" /> |
Un champ correspondant a également été ajouté aux assertions d'importation sur les importations de type uniquement ; cependant, il n'était pris en charge que dans les versions nocturnes de TypeScript. Le raisonnement était que dans l'esprit, les assertions d'importation n'étaient pas destinées à guider la résolution des modules. Cette fonctionnalité a donc été livrée à titre expérimental en mode "nightly only" afin d'obtenir davantage de retours.
Mais étant donné que les attributs d'importation peuvent guider la résolution, et que des cas d'utilisation raisonnables ont été observés, TypeScript 5.3 prend désormais en charge l'attribut resolution-mode pour type import.
Code:
1
2
3
4
5
6
7
8
9
10
11
| // Resolve `pkg` as if we were importing with a `require()`
import type { TypeFromRequire } from "pkg" with {
"resolution-mode": "require"
};
// Resolve `pkg` as if we were importing with an `import`
import type { TypeFromImport } from "pkg" with {
"resolution-mode": "import"
};
export interface MergedType extends TypeFromRequire, TypeFromImport {} |
Ces attributs d'importation peuvent également être utilisés sur les types import().
Code:
1
2
3
4
5
6
7
| export type TypeFromRequire =
import("pkg", { with: { "resolution-mode": "require" } }).TypeFromRequire;
export type TypeFromImport =
import("pkg", { with: { "resolution-mode": "import" } }).TypeFromImport;
export interface MergedType extends TypeFromRequire, TypeFromImport {} |
Support de resolution-mode dans tous les modes du module
Auparavant, l'utilisation de resolution-mode n'était autorisée que pour les options moduleResolution node16 et nodenext. Pour faciliter la recherche de modules spécifiques à des fins de type, resolution-mode fonctionne désormais de manière appropriée dans toutes les autres options moduleResolution telles que bundler, node10, et ne provoque tout simplement pas d'erreur sous classic.
Rétrécissement dans un switch (true)
TypeScript 5.3 peut maintenant effectuer un rétrécissement basé sur des conditions dans chaque clause case à l'intérieur d'un switch (true).
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| function f(x: unknown) {
switch (true) {
case typeof x === "string":
// 'x' is a 'string' here
console.log(x.toUpperCase());
// falls through...
case Array.isArray(x):
// 'x' is a 'string | any[]' here.
console.log(x.length);
// falls through...
default:
// 'x' is 'unknown' here.
// ...
}
} |
Rétrécissement sur des comparaisons avec des booléens
Il peut arriver que vous ayez à effectuer une comparaison directe avec true ou false dans une condition. Il s'agit généralement de comparaisons non nécessaires, mais vous pouvez les préférer pour des raisons de style ou pour éviter certains problèmes liés à la véracité de JavaScript. Quoi qu'il en soit, TypeScript ne reconnaissait pas ces formes lorsqu'il procédait à un rétrécissement.
TypeScript 5.3 se met désormais au diapason et comprend ces expressions lors du rétrécissement des variables.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| interface A {
a: string;
}
interface B {
b: string;
}
type MyType = A | B;
function isA(x: MyType): x is A {
return "a" in x;
}
function someFn(x: MyType) {
if (isA(x) === true) {
console.log(x.a); // works!
}
} |
Rétrécissement de instanceof avec Symbol.hasInstance
Une caractéristique légèrement ésotérique de JavaScript est qu'il est possible d'outrepasser le comportement de l'opérateur instanceof. Pour ce faire, la valeur à droite de l'opérateur instanceof doit avoir une méthode spécifique nommée par Symbol.hasInstance.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
| class Weirdo {
static [Symbol.hasInstance](testedValue) {
// wait, what?
return testedValue === undefined;
}
}
// false
console.log(new Thing() instanceof Weirdo);
// true
console.log(undefined instanceof Weirdo); |
Pour mieux modéliser ce comportement dans instanceof, TypeScript vérifie maintenant si une telle méthode [Symbol.hasInstance] existe et est déclarée comme une fonction de prédicat de type. Si c'est le cas, la valeur testée à gauche de l'opérateur instanceof sera restreinte de manière appropriée par ce prédicat de type.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
| interface PointLike {
x: number;
y: number;
}
class Point implements PointLike {
x: number;
y: number;
constructor(x: number, y: number) {
this.x = x;
this.y = y;
}
distanceFromOrigin() {
return Math.sqrt(this.x ** 2 + this.y ** 2);
}
static [Symbol.hasInstance](val: unknown): val is PointLike {
return !!val && typeof val === "object" &&
"x" in val && "y" in val &&
typeof val.x === "number" &&
typeof val.y === "number";
}
}
function f(value: unknown) {
if (value instanceof Point) {
// Can access both of these - correct!
value.x;
value.y;
// Can't access this - we have a 'PointLike',
// but we don't *actually* have a 'Point'.
value.distanceFromOrigin();
}
} |
Comme vous pouvez le voir dans cet exemple, Point définit sa propre méthode [Symbol.hasInstance]. Elle agit en fait comme une protection de type personnalisée sur un type distinct appelé PointLike. Dans la fonction f, il a été possible de réduire la valeur value à un PointLike avec instanceof, mais pas à un Point. Cela signifie qu'il est possible d'accéder aux propriétés x et y, mais pas à la méthode distanceFromOrigin.
Vérification des accès à la propriété super sur les champs d'instance
En JavaScript, il est possible d'accéder à une déclaration dans une classe de base grâce au mot-clé super.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| class Base {
someMethod() {
console.log("Base method called!");
}
}
class Derived extends Base {
someMethod() {
console.log("Derived method called!");
super.someMethod();
}
}
new Derived().someMethod();
// Prints:
// Derived method called!
// Base method called! |
Cela diffère de l'écriture de quelque chose comme this.someMethod(), puisque cela pourrait invoquer une méthode surchargée. Il s'agit d'une distinction subtile, rendue encore plus subtile par le fait que les deux peuvent souvent être interchangeables si une déclaration n'est jamais surchargée.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| class Base {
someMethod() {
console.log("someMethod called!");
}
}
class Derived extends Base {
someOtherMethod() {
// These act identically.
this.someMethod();
super.someMethod();
}
}
new Derived().someOtherMethod();
// Prints:
// someMethod called!
// someMethod called! |
Le problème de leur interchangeabilité est que super ne fonctionne que sur les membres déclarés dans le prototype - pas sur les propriétés d'instance. Cela signifie que si vous écrivez super.someMethod(), mais que someMethod est défini comme un champ, vous obtiendrez une erreur d'exécution.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| class Base {
someMethod = () => {
console.log("someMethod called!");
}
}
class Derived extends Base {
someOtherMethod() {
super.someMethod();
}
}
new Derived().someOtherMethod();
// *
// Doesn't work because 'super.someMethod' is 'undefined'. |
TypeScript 5.3 inspecte désormais de plus près les appels de la propriété accesses/method de super pour voir s'ils correspondent à des champs de classe. Si c'est le cas, une erreur de vérification de type se produit.
Indices d'incrustation interactifs pour les types
Les indices d'incrustation de TypeScript permettent désormais de sauter à la définition des types ! Cela facilite la navigation dans votre code.
Paramètres pour privilégier les auto-importations type
Auparavant, lorsque TypeScript générait des auto-importations pour quelque chose dans une position de type, il ajoutait un modificateur de type basé sur vos paramètres. Par exemple, lors de l'obtention d'un auto-import sur Person dans ce qui suit :
Code:
export let p: Person
l'expérience d'édition de TypeScript ajoutait généralement un import pour Person en tant que :
Code:
1
2
3
| import { Person } from "./types";
export let p: Person |
et sous certains paramètres comme verbatimModuleSyntax, il ajouterait le modificateur type :
Code:
1
2
3
| import { type Person } from "./types";
export let p: Person |
Cependant, il se peut que votre base de code ne soit pas en mesure d'utiliser certaines de ces options, ou que vous ayez simplement une préférence pour les importations type explicites lorsque c'est possible.
Grâce à une modification récente, TypeScript permet désormais de faire de cette option une option spécifique à l'éditeur. Dans Visual Studio Code, vous pouvez l'activer dans l'interface utilisateur sous "TypeScript > Preferences : Prefer Type Only Auto Imports", ou comme l'option de configuration JSON typescript.preferences.preferTypeOnlyAutoImports.
Optimisations en sautant l'analyse JSDoc
Lors de l'exécution de TypeScript via tsc, le compilateur évitera désormais d'analyser JSDoc. Cela réduit le temps d'analyse en soi, mais réduit également l'utilisation de la mémoire pour stocker les commentaires ainsi que le temps passé dans le garbage collection. Dans l'ensemble, vous devriez voir des compilations légèrement plus rapides et un retour d'information plus rapide en mode --watch.
Puisque tous les outils utilisant TypeScript n'auront pas besoin de stocker JSDoc (par exemple, typescript-eslint et Prettier), cette stratégie d'analyse a été intégrée à l'API elle-même. Cela peut permettre à ces outils de bénéficier des mêmes améliorations en termes de mémoire et de vitesse que celles qui ont été apportées au compilateur TypeScript. Les nouvelles options pour la stratégie d'analyse des commentaires sont décrites dans JSDocParsingMode.
Optimisations par comparaison d'intersections non normalisées
En TypeScript, les unions et les intersections suivent toujours une forme spécifique, où les intersections ne peuvent pas contenir de types d'union. Cela signifie que lorsque nous créons une intersection sur une union comme A & (B | C), cette intersection sera normalisée en (A & B) | (A & C). Cependant, dans certains cas, le système de types conservera la forme originale à des fins d'affichage.
Il s'avère que la forme originale peut être utilisée pour des comparaisons rapides et astucieuses entre les types.
Par exemple, disons que nous avons SomeType & (Type1 | Type2 | ... | Type99999NINE) et que nous voulons voir s'il est assignable à SomeType. Rappelons que nous n'avons pas vraiment d'intersection comme type source - nous avons une union qui ressemble à (SomeType & Type1) | (SomeType & Type2) | ... ... | (SomeType & Type99999NINE). Lorsqu'on vérifie si une union est assignable à un type cible, on doit vérifier si chaque membre de l'union est assignable au type cible, ce qui peut être très lent.
Dans TypeScript 5.3, un coup d'œil est donné à la forme d'intersection originale qui avait été mise de côté. Lorsque les types sont comparés, une vérification rapide est effectuée pour voir si la cible existe dans l'un des constituants de l'intersection source.
Consolidation entre tsserverlibrary.js et typescript.js
TypeScript est livré avec deux fichiers de bibliothèque : tsserverlibrary.js et typescript.js. Certaines API ne sont disponibles que dans tsserverlibrary.js (comme l'API ProjectService), ce qui peut être utile à certains importateurs. Cependant, les deux paquets sont distincts et se chevauchent beaucoup, dupliquant le code dans le paquet. De plus, il peut être difficile d'utiliser systématiquement l'un plutôt que l'autre en raison des importations automatiques ou de la mémoire musculaire. Il est beaucoup trop facile de charger accidentellement les deux modules, et le code peut ne pas fonctionner correctement sur une instance différente de l'API. Même s'il fonctionne, le chargement d'un second bundle augmente l'utilisation des ressources.
Dans ces conditions, il a été décidé de consolider les deux modules. typescript.js contient désormais ce que tsserverlibrary.js contenait auparavant, et tsserverlibrary.js ré-exporte simplement typescript.js. En comparant l'avant/après de cette consolidation, la réduction de la taille des paquets est la suivante :
En d'autres termes, il s'agit d'une réduction de plus de 20,5 % de la taille des paquets.
Changements importants et améliorations de la correction
Changements dans lib.d.ts
Les types générés pour le DOM peuvent avoir un impact sur votre base de code.
Vérification des accès super sur les propriétés d'instance
TypeScript 5.3 détecte maintenant quand la déclaration référencée par une propriété d'accès super. est un champ de classe et émet une erreur. Cela permet d'éviter les erreurs qui pourraient survenir lors de l'exécution.
Quelles sont les prochaines étapes ?
Bien que le plan d'itération ne soit pas encore public, Microsoft travaille d'ores et déjà sur TypeScript 5.4. Il est prévu que TypeScript 5.4 ait une version stable vers la fin du mois de février 2024.
Source : Microsoft
Et vous ?
:fleche: Que pensez-vous de cette version 5.3 de TypeScript et des fonctionnalités qu'elle propose ?
:fleche: Quelles sont les fonctionnalités que vous aimeriez retrouver dans la prochaine version de TypeScript ?
Voir aussi
:fleche: Microsoft annonce la disponibilité de TypeScript 5.3 Release Candidate, documentant le resolution-mode et ajoutant une option de préférence pour l'importation automatique des Type
:fleche: Microsoft annonce la disponibilité de TypeScript 5.3 Beta, et présente une liste rapide des nouveautés de TypeScript 5.3 Beta
