Dans sa feuille de route de TypeScript pour les six premiers mois de 2019, Microsoft envisage des améliorations dans le système de typage, dans la qualité du code et sur la prise en compte des messages d’erreur.

Microsoft a dernièrement communiqué ses priorités sur la feuille de route de son langage de programmation open source TypeScript pour le premier semestre 2019. Celles-ci portent principalement sur l’amélioration du système de typage du langage de programmation, sur l’augmentation de la productivité et sur la qualité d’écriture de code. Dans un billet sur Github, Daniel Rosenwasser, responsable de programme sur TypeScript chez Microsoft, souligne que cette organisation peut être ajustée sur la période « en fonction de l’évolution des besoins et des retours des utilisateurs ». Cette feuille de route ne vaut donc pas engagement de livraison des fonctionnalités.

Pour TypeScript et son système de typage, l’objectif est de modéliser statiquement les modèles en JavaScript d’une manière prudente tout en renforçant l’exactitude du code et en corrigeant les bugs. Les fonctionnalités ajoutées à la spécification ECMAScript sous-jacente à JavaScript signifient que TypeScript doit évoluer avec elle. Les priorités pour TypeScript et son système de typage sont les suivantes : l’activation des modèles JavaScript populaires d’une manière rassurée, l’expressivité accrue, la preuve des relations entre les types, la mise en œuvre des fonctionnalités ECMAScript, ainsi qu’un paramétrage plus strict.

Au-delà de TypeScript

Étant donné que la base d’utilisateurs inclut désormais l’écosystème JavaScript tout entier, TypeScript n’est plus seulement réservé à TypeScript. Dans cette optique, les priorités de Microsoft recouvrent une transition plus lisse vers TypeScript, une compréhension des modèles plus dynamiques, une amélioration de l’édition JavaScript et une automatisation pour l’ajout des types JSDoc. En termes de productivité, l’éditeur de Redmond énumère plusieurs objectifs. Ceux-ci regroupent des corrections rapides « proactives », des corrections et remaniements du fichier de déclaration, la migration plus facile vers TypeScript et le JavaScript typé, ainsi que des corrections et refactorings étendus, pour les changements de classe de code et les corrections applicables à la plupart des développeurs.

ESLint vs TSLint

Des perfectionnements sont également à l’étude pour les « lint ». Pour vérifier la qualité du code, Microsoft pourrait préconiser l’usage de l’utilitaire de linting enfichable ESLint pour JavaScript à la place de l’utilitaire d’analyse statique TSLint pour le code TypeScript. La firme de Redmond prévoit de contribuer au support TypeScript d’ESLint pour l’amener à la parité avec TSLint. Le référentiel de TypeScript passera à ESLint.

En matière de vitesse, de stabilité et d’évolutivité, trois priorités ont été fixées. Premièrement, il s’agit de résoudre les problèmes de performance, y compris le suivi et la correction des régressions, notamment les régressions en temps d’émission et les problèmes de performance dans l’IDE Visual Studio. Deuxièmement, permettre le déchargement automatique des projets dans le serveur autonome TSServer pour TypeScript. Troisièmement, progresser en continu les projets composites, pour construire des projets colocalisés pour des scénarios comme les applications monorepos, à référentiel unique, et serverless. Le support est planifié pour l’entrée et la sortie automatique des projets pour économiser de la mémoire. Pour les expériences de ligne de commande, Microsoft envisage de faire apparaître les opérations de service de langage sur la ligne de commande. Les utilisateurs ont demandé des solutions pour déclencher des opérations comme « organiser les importations » et appliquer automatiquement les transformations de code utilisées par les corrections rapides et le refactoring.

Expérience utilisateur sur l’affichage des erreurs

Dans TypeScript, l’expérience utilisateur sur les erreurs permet aux développeurs de comprendre ce que fait le système de typage. Mais l’UX n’a pas suivi les progrès du système. Les utilisateurs moins expérimentés ont besoin d’être guidés rapidement vers les solutions avec une expérience utilisateur sur les erreurs qui soit précise mais facile à aborder, explique Microsoft. Il prévoit ainsi de prioriser les messages d’erreur trompeurs que les utilisateurs classent. De plus, les messages d’erreur pourraient être plus accessibles dans les éditeurs, permettre particulièrement aux utilisateurs d’avoir accès à une explication complète d’une erreur sur demande.