Aujourd'hui, nous sommes heureux d'annoncer la sortie de TypeScript 5.0 ! Cette version apporte de nombreuses nouvelles fonctionnalités, tout en visant à rendre TypeScript plus petit, plus simple et plus rapide. Nous avons implémenté le nouveau standard des décorateurs, ajouté des fonctionnalités pour mieux supporter les projets ESM dans Node et les bundlers, fourni de nouvelles façons pour les auteurs de bibliothèques de contrôler l'inférence générique, étendu notre fonctionnalité JSDoc, simplifié la configuration, et apporté beaucoup d'autres améliorations.Si vous ne connaissez pas encore TypeScript, il s'agit d'un langage qui s'appuie sur JavaScript en ajoutant une syntaxe pour les types qui peuvent être utilisés pour la vérification de type. Le contrôle de type permet de détecter de nombreuses erreurs courantes, des fautes de frappe aux erreurs de logique. L'ajout de types à JavaScript nous permet également de construire des outils performants, puisque les types peuvent alimenter des fonctionnalités telles que les complétions de code, les définitions de type, et les refactorings dans votre éditeur favori. En fait, si vous avez utilisé des éditeurs comme Visual Studio ou VS Code, TypeScript vous offre déjà l'expérience JavaScript !
Mais si vous connaissez déjà TypeScript, n'ayez crainte ! La version 5.0 n'est pas un bouleversement, et tout ce que vous savez est encore applicable. Bien que TypeScript 5.0 comprenne des changements de correction et quelques dépréciations pour des options peu utilisées, nous pensons que la plupart des développeurs auront une expérience de mise à jour similaire à celle des versions précédentes.
Pour commencer à utiliser TypeScript 5.0, vous pouvez l'obtenir via NuGet, ou utiliser npm avec la commande suivante :
| Code : | Sélectionner tout |
npm install -D typescript
Quelles sont les nouveautés depuis la Beta et la RC ?
TypeScript 5.0 a connu plusieurs changements notables depuis notre version bêta.
Une nouvelle différence depuis TypeScript 5.0 Beta est que TypeScript permet aux décorateurs d'être placés avant ou après export et export default. Ce changement reflète les discussions et le consensus au sein du TC39, l'organisme de normalisation pour ECMAScript/JavaScript.
Par ailleurs, la nouvelle option de résolution de module du bundler ne peut désormais être utilisée que lorsque l'option --module est définie sur esnext. Ceci a été fait pour s'assurer que les instructions import écrites dans les fichiers d'entrée ne seront pas transformées en appels require avant que le bundler ne les résolve, que le bundler ou le chargeur respecte ou non l'option module de TypeScript. Nous avons également fourni un certain contexte dans ces notes de mise à jour en recommandant à la plupart des auteurs de bibliothèques de s'en tenir à node16 ou nodenext.
Bien que TypeScript 5.0 Beta ait été livré avec cette fonctionnalité, nous n'avons pas documenté notre travail sur la prise en charge du tri des importations non-sensibles à la casse dans les scénarios de l'éditeur. C'est en partie parce que l'interface utilisateur pour la personnalisation est encore en discussion, mais par défaut, TypeScript devrait maintenant fonctionner mieux avec le reste de votre outillage.
Depuis notre RC, notre changement le plus notable est que TypeScript 5.0 spécifie maintenant une version minimale de Node.js de 12.20 dans notre package.json. Nous avons également publié un article sur la migration de TypeScript 5.0 vers les modules, et y avons ajouté un lien.
Depuis l'annonce de TypeScript 5.0 Beta et RC, les chiffres spécifiques pour les benchmarks de vitesse et les deltas de taille de paquet ont également été ajustés, bien que le bruit ait été un facteur dans toutes les exécutions. Les noms de certains benchmarks ont également été ajustés pour plus de clarté, et les améliorations de la taille des paquets ont été déplacées dans un tableau séparé.
Différences avec les anciens décorateurs expérimentaux
En plus de permettre aux décorateurs d'être placés avant le mot-clé export, la proposition relative aux décorateurs offre désormais la possibilité de placer les décorateurs après l'exportation ou l'exportation par défaut. La seule exception est que le mélange des deux styles n'est pas autorisé.
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | // allowed
@register export default class Foo {
// ...
}
// also allowed
export default @register class Bar {
// ...
}
// error - before *and* after is not allowed
@before export @after class Bar {
// ...
} |
Bundler --moduleResolution
TypeScript 4.7 a introduit les options node16 et nodenext pour ses paramètres --module et --moduleResolution. L'intention de ces options était de mieux modéliser les règles de recherche précises pour les modules ECMAScript dans Node.js ; cependant, ce mode a de nombreuses restrictions que d'autres outils n'appliquent pas vraiment.
Par exemple, dans un module ECMAScript de Node.js, toute importation relative doit inclure une extension de fichier.
| Code : | Sélectionner tout |
1 2 3 4 5 | // entry.mjs import * as utils from "./utils"; // wrong - we need to include the file extension. import * as utils from "./utils.mjs"; // works |
Il y a certaines raisons à cela dans Node.js et le navigateur - cela rend les recherches de fichiers plus rapides et fonctionne mieux pour les serveurs de fichiers naïfs. Mais pour de nombreux développeurs utilisant des outils tels que les bundlers, les paramètres node16/nodenext étaient encombrants car les bundlers n'ont pas la plupart de ces restrictions. D'une certaine manière, le mode de résolution de node était meilleur pour tous ceux qui utilisaient un bundler.
Mais d'un autre côté, le mode de résolution original de node était déjà dépassé. La plupart des bundlers modernes utilisent une fusion du module ECMAScript et des règles de recherche CommonJS dans Node.js. Par exemple, les importations sans extension fonctionnent parfaitement comme dans CommonJS, mais lorsque l'on examine les conditions d'exportation d'un paquet, on préfère une condition import comme dans un fichier ECMAScript.
Pour modéliser le fonctionnement des bundlers, TypeScript introduit maintenant une nouvelle stratégie : --moduleResolution bundler.
| Code : | Sélectionner tout |
1 2 3 4 5 6 | {
"compilerOptions": {
"target": "esnext",
"moduleResolution": "bundler"
}
} |
Si vous utilisez un bundler moderne comme Vite, esbuild, swc, Webpack, Parcel, et d'autres qui implémentent une stratégie de recherche hybride, la nouvelle option bundler devrait vous convenir.
D'un autre côté, si vous écrivez une bibliothèque destinée à être publiée sur npm, l'utilisation de l'option bundler peut cacher des problèmes de compatibilité qui peuvent survenir pour vos utilisateurs qui n'utilisent pas de bundler. Dans ce cas, l'utilisation des options de résolution node16 ou nodenext est probablement la meilleure solution.
Tri des importations non-sensibles à la casse dans les éditeurs
Dans les éditeurs comme Visual Studio et VS Code, TypeScript permet d'organiser et de trier les importations et les exportations. Souvent, cependant, il peut y avoir différentes interprétations du moment où une liste est "triée".
Par exemple, la liste d'importation suivante est-elle triée ?
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 | import {
Toggle,
freeze,
toBoolean,
} from "./utils"; |
La réponse pourrait être étonnamment "ça dépend". Si nous ne tenons pas compte de la sensibilité à la casse, il est clair que cette liste n'est pas triée. La lettre f précède à la fois t et T.
Mais dans la plupart des langages de programmation, le tri se fait par défaut en comparant les valeurs d'octets des chaînes de caractères. La façon dont JavaScript compare les chaînes signifie que "Toggle" vient toujours avant "freeze" parce que, selon le codage des caractères ASCII, les majuscules viennent avant les minuscules. De ce point de vue, la liste des importations est donc triée.
TypeScript considérait auparavant que la liste d'importation était triée parce qu'il effectuait un tri de base sensible à la casse. Cela pouvait être une source de frustration pour les développeurs qui préféraient un ordre insensible à la casse, ou qui utilisaient des outils comme ESLint qui exigent un ordre insensible à la casse par défaut.
TypeScript détecte désormais la sensibilité à la casse par défaut. Cela signifie que TypeScript et des outils comme ESLint ne se "battent" généralement pas entre eux sur la meilleure façon de trier les importations.
Notre équipe a également expérimenté d'autres stratégies de tri. Ces options pourront éventuellement être configurées par les éditeurs. Pour l'instant, elles sont encore instables et expérimentales, et vous pouvez les utiliser dans VS Code dès aujourd'hui en utilisant l'entrée typescript.unstable dans vos options JSON. Vous trouverez ci-dessous toutes les options que vous pouvez essayer (avec leurs valeurs par défaut) :
| Code : | Sélectionner tout |
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 39 40 41 42 43 | {
"typescript.unstable": {
// Should sorting be case-sensitive? Can be:
// - true
// - false
// - "auto" (auto-detect)
"organizeImportsIgnoreCase": "auto",
// Should sorting be "ordinal" and use code points or consider Unicode rules? Can be:
// - "ordinal"
// - "unicode"
"organizeImportsCollation": "ordinal",
// Under `"organizeImportsCollation": "unicode"`,
// what is the current locale? Can be:
// - [any other locale code]
// - "auto" (use the editor's locale)
"organizeImportsLocale": "en",
// Under `"organizeImportsCollation": "unicode"`,
// should upper-case letters or lower-case letters come first? Can be:
// - false (locale-specific)
// - "upper"
// - "lower"
"organizeImportsCaseFirst": false,
// Under `"organizeImportsCollation": "unicode"`,
// do runs of numbers get compared numerically (i.e. "a1" < "a2" < "a100")? Can be:
// - true
// - false
"organizeImportsNumericCollation": true,
// Under `"organizeImportsCollation": "unicode"`,
// do letters with accent marks/diacritics get sorted distinctly
// from their "base" letter (i.e. is é different from e)? Can be
// - true
// - false
"organizeImportsAccentCollation": true
},
"javascript.unstable": {
// same options valid here...
},
} |
Optimisation de la vitesse, de la mémoire et de la taille des paquets
TypeScript 5.0 contient de nombreux changements puissants dans notre structure de code, nos structures de données et nos implémentations algorithmiques. Cela signifie que l'ensemble de votre expérience devrait être plus rapide - non seulement en exécutant TypeScript, mais aussi en l'installant.
Voici quelques gains intéressants en termes de vitesse et de taille que nous avons pu réaliser par rapport à TypeScript 4.9.
Comment ? Il y a quelques améliorations notables sur lesquelles nous aimerions donner plus de détails à l'avenir. Mais nous ne vous ferons pas attendre ce billet de blog.
Tout d'abord, nous avons récemment migré TypeScript des espaces de noms vers les modules, ce qui nous permet d'exploiter des outils de construction modernes capables d'effectuer des optimisations telles que le scope hoisting. L'utilisation de cet outil, la révision de notre stratégie d'empaquetage et la suppression de certains codes obsolètes nous ont permis de gagner environ 26,4 Mo sur les 63,8 Mo de TypeScript 4.9. Cela nous a également apporté une accélération notable grâce aux appels directs de fonctions.
TypeScript a également ajouté plus d'uniformité aux types d'objets internes dans le compilateur, et a également allégé les données stockées sur certains de ces types d'objets. Cela a permis de réduire les opérations polymorphes, tout en équilibrant l'augmentation de l'utilisation de la mémoire résultant de l'uniformisation des formes d'objets.
Nous avons également procédé à une mise en cache lors de la sérialisation des informations en chaînes de caractères. L'affichage des types, qui peut se produire dans le cadre d'un rapport d'erreur, d'une émission de déclaration, d'une complétion de code, et plus encore, peut s'avérer assez coûteux. TypeScript met désormais en cache certaines machines couramment utilisées afin de les réutiliser dans le cadre de ces opérations.
Un autre changement notable que nous avons effectué et qui a amélioré notre analyseur est l'utilisation de var pour contourner occasionnellement le coût de l'utilisation de let et const dans les fermetures. Cela a permis d'améliorer certaines de nos performances d'analyse.
Dans l'ensemble, nous pensons que la plupart des bases de code devraient bénéficier d'améliorations de vitesse grâce à TypeScript 5.0, et nous avons toujours été en mesure de reproduire des gains de 10 à 20 %. Bien sûr, cela dépendra du matériel et des caractéristiques de la base de code, mais nous vous encourageons à l'essayer sur votre base de code dès aujourd'hui !
Exigences d'exécution
TypeScript vise désormais ECMAScript 2018. Le package TypeScript a également défini un moteur minimum attendu de 12.20. Pour les utilisateurs de Node, cela signifie que TypeScript 5.0 nécessite une version minimale de Node.js 12.20 et plus.
What's Next ?
Sans vouloir nous avancer, TypeScript 5.1 est déjà en préparation, et tous nos plans sont déjà sur GitHub. Si vous êtes impatient, nous vous encourageons à essayer nos nightly builds de TypeScript ou l'extension JavaScript et TypeScript Nightly pour VS Code !
Bien sûr, nous ne serons pas déçus si vous choisissez d'apprécier la nouvelle version stable de TypeScript. Nous espérons que TypeScript 5.0 rendra le codage plus rapide et plus amusant pour tout le monde.
Joyeux hacking !
- Daniel Rosenwasser et l'équipe TypeScript
Source : Microsoft
Et vous ?
Quel est votre avis sur le sujet ? Quelles sont les fonctionnalités que vous aimeriez retrouver dans la version 5.1 de Typescript ?Voir aussi
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 Microsoft annonce la migration de TypeScript 5.0 vers les modules ECMAScript, pour le doter d'une base de code plus moderne, d'une interface améliorée et de performances plus accrues Microsoft annonce la disponibilité de TypeScript 4.9 qui se dote du nouvel opérateur « satisfies », améliore l'opérateur « in » et prend déjà en charge les accesseurs automatiques d'ECMAScript