Microsoft annonce la disponibilité de TypeScript 5.5 RC (Release Candidate)

Cette version prend en charge les nouvelles méthodes ECMAScript Set et améliore la fiabilité de l'éditeur et du mode veille

Microsoft annonce la disponibilité de la version candidate de TypeScript 5.5.

Voici une liste rapide des nouveautés de TypeScript 5.5 :

• Prédicats de type inférés
• Réduction du flux de contrôle pour les accès indexés constants
• Importations de types dans JSDoc
• Vérification syntaxique des expressions régulières
• Déclarations isolées
• La variable modèle ${configDir} pour les fichiers de configuration
• Consultation des dépendances package.json pour la génération de fichiers de déclaration
• Amélioration de la fiabilité de l'éditeur et du mode veille
• Optimisation des performances et de la taille
• Modules ECMAScript de consommation d'API plus faciles à utiliser
• API transpileDeclaration

Une partie de ces nouveautés sont détaillées dans l'annonce de TypeScript 5.5 Beta. Pour TypeScript 5.5 RC, Microsoft a ajouté la prise en charge des nouvelles méthodes ECMAScript Set. De plus, ils ont ajusté le comportement de la nouvelle vérification des expressions régulières de TypeScript pour être légèrement plus indulgent, tout en continuant à faire des erreurs sur les échappements douteux qui ne sont autorisés que par l'annexe B d'ECMAScript.

Microsoft a également ajouté et documenté encore plus d'optimisations de performance : notamment, la vérification sautée dans transpileModule et les optimisations dans la façon dont TypeScript filtre les types contextuels. Ces optimisations peuvent conduire à des temps de construction et d'itération plus rapides dans de nombreux scénarios courants.


Prise en charge des nouvelles méthodes ECMAScript Set

TypeScript 5.5 déclare de nouvelles méthodes proposées pour le type ECMAScript Set.

Certaines de ces méthodes, comme union, intersection, différence et symmetricDifference, prennent un autre Set et renvoient un nouveau Set comme résultat. Les autres méthodes, isSubsetOf, isSupersetOf et isDisjointFrom, prennent un autre ensemble et renvoient un booléen. Aucune de ces méthodes ne modifie les ensembles d'origine.

Consultation des dépendances package.json pour la génération du fichier de déclaration

Auparavant, TypeScript affichait souvent un message d'erreur du type :

Cela était souvent dû au fait que la génération du fichier de déclaration de TypeScript se retrouvait dans le contenu de fichiers qui n'avaient jamais été explicitement importés dans un programme. Générer une importation dans un tel fichier pouvait être risqué si le chemin d'accès s'avérait être relatif. Néanmoins, pour les bases de code avec des dépendances explicites dans les dependencies (ou peerDependencies et optionalDependencies) d'un package.json, la génération d'un tel import devrait être sûre sous certains modes de résolution. Ainsi, dans TypeScript 5.5, Microsoft est plus indulgents lorsque c'est le cas, et de nombreuses occurrences de cette erreur devraient disparaître.

Amélioration de la fiabilité de l'éditeur et du mode veille

TypeScript a ajouté de nouvelles fonctionnalités ou corrigé la logique existante qui rend le mode --watch et l'intégration de l'éditeur TypeScript plus fiables. Cela devrait se traduire par moins de redémarrages de TSServer/éditeur.

Rafraîchissement correct des erreurs de l'éditeur dans les fichiers de configuration

TypeScript peut générer des erreurs pour les fichiers tsconfig.json ; cependant, ces erreurs sont en fait générées lors du chargement d'un projet, et les éditeurs ne demandent généralement pas directement ces erreurs pour les fichiers tsconfig.json. Bien que cela semble être un détail technique, cela signifie que lorsque toutes les erreurs émises dans un fichier tsconfig.json sont corrigées, TypeScript n'émet pas un nouvel ensemble d'erreurs fraîches et vides, et les utilisateurs se retrouvent avec des erreurs périmées à moins qu'ils ne rechargent leur éditeur.

TypeScript 5.5 émet désormais intentionnellement un événement pour effacer ces erreurs.

Meilleure gestion des suppressions suivies d'écritures immédiates

Au lieu d'écraser les fichiers, certains outils choisissent de les supprimer et de créer de nouveaux fichiers à partir de zéro. C'est le cas lors de l'exécution de npm ci, par exemple.

Si cela peut être efficace pour ces outils, cela peut être problématique pour les scénarios de l'éditeur TypeScript où la suppression d'un fichier surveillé peut l'éliminer ainsi que toutes ses dépendances transitives. La suppression et la création d'un fichier en succession rapide peuvent conduire TypeScript à démanteler un projet entier et à le reconstruire à partir de zéro.

TypeScript 5.5 a désormais une approche plus nuancée en conservant des parties d'un projet supprimé jusqu'à ce qu'il détecte un nouvel événement de création. Cela devrait permettre à des opérations comme npm ci de mieux fonctionner avec TypeScript.

Les liens symboliques sont suivis dans les résolutions échouées

Lorsque TypeScript échoue à résoudre un module, il devra toujours surveiller les chemins de recherche qui ont échoué dans le cas où le module est ajouté plus tard. Auparavant, cela n'était pas fait pour les répertoires liés par des liens symboliques, ce qui pouvait causer des problèmes de fiabilité dans des scénarios de type monorepo lorsqu'une construction se produisait dans un projet mais n'était pas observée dans l'autre. Ce problème devrait être corrigé dans TypeScript 5.5, ce qui signifie que vous n'aurez plus besoin de redémarrer votre éditeur aussi souvent.

Les références de projet contribuent aux importations automatiques

Les importations automatiques ne nécessitent plus au moins une importation explicite vers des projets dépendants dans une configuration de référence de projet. Au lieu de cela, les compléments d'auto-importation devraient fonctionner pour tout ce que vous avez listé dans le champ references de votre tsconfig.json.

Optimisation des performances et de la taille

Objets monomorphisés dans le service linguistique et l'API publique

Dans TypeScript 5.0, les objets Node et Symbol avaient un ensemble cohérent de propriétés avec un ordre d'initialisation cohérent. Cela permet de réduire le polymorphisme dans les différentes opérations, ce qui permet aux moteurs d'exécution d'aller chercher les propriétés plus rapidement.

En apportant ce changement, Microsoft a constaté des gains de vitesse impressionnants dans le compilateur ; cependant, la plupart de ces changements ont été effectués sur les allocateurs internes pour les structures de données. Le service linguistique, ainsi que l'API publique de TypeScript, utilisent un ensemble différent d'allocateurs pour certains objets. Cela a permis au compilateur TypeScript d'être un...