TypeScript n'est plus vraiment TypeScript...

Françaisالعربية Deutsch English Español हिन्दी Bahasa Indonesia 日本語 한국어 Português Русский 中文

Computing/SoftwareInternet Technology

Transcript

00:00:00TypeScript vient de publier une version candidate pour la version 7 et ce sera la version où

00:00:04TypeScript n'est plus du TypeScript. Si vous n'étiez pas au courant, ils travaillaient sur la réécriture du

00:00:07compilateur TypeScript, passant de TypeScript lui-même à Go, et apparemment, les résultats sont 10 fois plus rapides.

00:00:12Ils prévoient de sortir TypeScript 7 le mois prochain, alors passons en revue ce qui a réellement changé,

00:00:17à quel point c'est rapide, et s'il y a des changements cassants à connaître avant de l'installer.

00:00:26Donc, si vous avez manqué la nouvelle sur le portage vers Go, ils ont commencé il y a environ un an,

00:00:29et le TL;DR est qu'ils ont réalisé que JavaScript n'a jamais été conçu pour le travail intensif lié au CPU

00:00:34qu'un vérificateur de types effectue. Ils ont donc commencé à le réécrire en Go avec un grand succès initial. Ils ont commencé par

00:00:39porter essentiellement l'implémentation existante de TypeScript, ligne par ligne, donc la logique

00:00:44de vérification de type était structurellement identique et avait le même comportement, et vous pouviez même voir certaines

00:00:48des fonctions qui étaient presque identiques, à part le langage. Je suis aussi assez sûr que c'était avant

00:00:52qu'on puisse juste demander à Claude de migrer sa base de code vers le langage souhaité.

00:00:56Je te regarde, Bun. Les résultats du portage parlent d'eux-mêmes. Ici, j'ai le

00:01:00dépôt Playwright, et si j'effectue une vérification de type en utilisant l'ancienne version de TypeScript, on peut voir que

00:01:04cela prend environ six secondes pour se terminer, et cela a parcouru 1400 fichiers et un demi-million de lignes de

00:01:08code. Si je passe maintenant à la version candidate sans rien changer à part cette commande,

00:01:12au total, cela a pris 0,87 seconde. C'est une amélioration sérieuse. Cela a aussi trouvé exactement le même nombre

00:01:18d'erreurs, les mêmes erreurs, et a parcouru les mêmes fichiers et lignes de code, donc ça fonctionne exactement

00:01:23de la même manière que TypeScript 6. Le code natif de Go est simplement fondamentalement plus rapide que JavaScript pour une

00:01:27tâche comme celle-ci, mais cela leur permet aussi d'utiliser le parallélisme à mémoire partagée. Là où le compilateur JavaScript

00:01:32était mono-thread, Go peut répartir cette vérification de type sur plusieurs cœurs à la fois. Dans TypeScript

00:01:377, vous pouvez l'obliger à être mono-thread avec un flag, si jamais vous faites du débogage

00:01:41ou si vous tournez sur une machine avec des ressources limitées. Et si je fais cela dans la base de code de Playwright

00:01:46ici avec TypeScript 7, on voit qu'en mono-thread, cela prend environ deux secondes, ce qui est

00:01:50toujours trois fois plus rapide qu'avant. En parlant d'exécution en parallèle, ils exposent aussi

00:01:54un nouveau flag “checkers” qui vous permet de définir combien de travailleurs de vérification de type peuvent fonctionner en parallèle,

00:01:58et cela est réglé par défaut sur quatre. Augmenter cela pourrait accélérer vos builds sur de plus grandes bases de code si vous

00:02:03avez beaucoup de cœurs CPU, mais cela se fera au prix d'une utilisation mémoire accrue. Si je règle les “checkers”

00:02:08sur 8 dans ce dépôt Playwright, ce qui est le double du défaut, cela semble effectivement réduire encore d'un

00:02:12tiers le temps nécessaire. Il y a aussi un nouveau flag “builders” pour paralléliser les builds de références de projets, aka construire

00:02:16plusieurs projets à la fois, et ce flag vous permet de contrôler le nombre de “builders” parallèles qui peuvent

00:02:20s'exécuter en même temps. Il est bon de noter que si vous combinez cela avec les “checkers” que nous venons de voir, disons

00:02:24que vous en avez quatre de chaque, cela signifie que vous pouvez avoir jusqu'à 16 vérificateurs de type s'exécutant simultanément. À part

00:02:29les changements de code natif et le parallélisme, une autre grosse réécriture dans TypeScript 7 a été son mode “watch”.

00:02:34Lorsqu'ils ont porté vers Go, c'était un peu plus délicat car la bibliothèque standard ne fournit pas

00:02:38d'API de surveillance de fichiers intégrée, et les bibliothèques tierces qu'ils ont essayées avaient des problèmes de

00:02:43stabilité, performance et support multiplateforme. L'équipe a donc regardé l'outil de surveillance de fichiers du bundler Parcel,

00:02:47que Microsoft utilise un peu dans VS Code, mais comme c'était en C++, ils ont également

00:02:53dû porter les parties nécessaires en Go également. La bonne nouvelle est qu'ils ont tout fait,

00:02:57et cela semble fonctionner vraiment bien, et mieux qu'avant. Ensuite, puisque c'est

00:03:01un changement de version majeure, vous pourriez vous attendre à beaucoup de changements cassants, surtout que c'est une grosse

00:03:05réécriture, mais je ne pense pas qu'il y en ait vraiment si vous passez de TypeScript 6 à 7. Si

00:03:10vous voulez passer de 5 à 7, il y en aura pas mal, donc ils recommandent de

00:03:14passer d'abord à la version 6, de tout faire fonctionner, et ensuite le passage à la version 7 devrait se faire sans problème. Quelques-uns

00:03:19des gros changements dans TypeScript 6 étaient la suppression de la cible ES5, la suppression de baseUrl et la dépréciation des systèmes

00:03:24de modules AMD, UMD et SystemJS. Ils ont aussi mis “strict” à “true” par défaut, défini “module” sur “esnext” par défaut,

00:03:31et la cible par défaut est la version ECMAScript stable actuelle précédant immédiatement “esnext”. C'était

00:03:36essentiellement laisser le passé derrière soi et moderniser TypeScript, ce que j'apprécie vraiment car

00:03:40parfois, essayer de supporter des projets hérités dans chaque version que vous créez peut vraiment ralentir le

00:03:45progrès d'un outil. En regardant le reste de cet article de blog, il semble que la seule nouvelle

00:03:49fonctionnalité ou changement qui concerne réellement le langage TypeScript lui-même, c'est que les types de littéraux de gabarit

00:03:53préservent désormais les points de code Unicode. Essentiellement, avant TypeScript 7, TypeScript séparait en unités de code UTF-16,

00:03:59donc cela finissait par couper une emoji en deux, et vous vous retrouviez avec ces types bizarres pour les têtes

00:04:04et les queues. Dans TypeScript 7, cependant, cela sépare sur des points de code entiers, donc des caractères complets,

00:04:09donc maintenant l'emoji est préservée et la séparation est à peu près comme vous vous y attendriez. Je serais

00:04:13honnêtement incroyablement impressionné si l'un d'entre vous a déjà rencontré cela en utilisant TypeScript.

00:04:18Dans l'ensemble, ces changements devraient rendre tout ce qui utilise TypeScript beaucoup plus rapide, comme TypeScript

00:04:22dans votre éditeur, surtout pour les grands projets. La version stable est prévue dans environ un mois,

00:04:27mais une API programmatique stable, donc ce que les auteurs d'outils utilisent pour construire au-dessus du compilateur,

00:04:32arrive dans la version 7.1. À cause de cela, il y a aussi un paquet de compatibilité, donc vous pouvez exécuter

00:04:36TypeScript 6 et 7 côte à côte sans rencontrer de conflits. Dites-moi ce que vous pensez de tout

00:04:41cela, et je suis curieux de savoir si vous avez déjà trouvé que TypeScript semblait lent. Dites-le-moi dans

00:04:44les commentaires. Pendant que vous y êtes, abonnez-vous, et comme toujours, on se voit dans la prochaine.

Key Takeaway

La réécriture du compilateur TypeScript en Go permet une amélioration spectaculaire des performances, atteignant une exécution jusqu'à 10 fois plus rapide grâce au parallélisme natif.

Highlights

TypeScript 7 est réécrit en Go, ce qui permet d'atteindre une vitesse de vérification de type jusqu'à 10 fois supérieure.
La vérification de type sur le dépôt Playwright passe de 6 secondes avec l'ancienne version à 0,87 seconde avec TypeScript 7.
Le nouveau compilateur utilise le parallélisme à mémoire partagée pour répartir la charge de travail sur plusieurs cœurs CPU au lieu d'être limité à un seul thread.
Le flag “checkers” permet de définir le nombre de travailleurs parallèles, avec une valeur par défaut de 4.
Le mode “watch” a été entièrement réécrit en Go, en utilisant une implémentation basée sur le système de surveillance de fichiers de Parcel.
Les types de littéraux de gabarit préservent désormais les points de code Unicode entiers, évitant ainsi de diviser les émojis en unités UTF-16.

Timeline

Réécriture du compilateur en Go

TypeScript 7 adopte le langage Go pour améliorer ses performances intensives en CPU.
Le portage permet d'atteindre une vitesse de compilation 10 fois supérieure tout en conservant une logique de vérification identique à la version précédente.

JavaScript n'était pas conçu pour la charge intensive requise par un vérificateur de types moderne. L'équipe a initialement porté le code ligne par ligne pour garantir une cohérence comportementale totale. Les résultats sur des projets d'envergure, comme Playwright, montrent une réduction drastique du temps de traitement.

Parallélisme et nouvelles configurations

TypeScript 7 exploite le parallélisme pour répartir la vérification de type sur plusieurs cœurs.
Le flag “checkers” permet de contrôler le nombre de travailleurs parallèles, avec une valeur par défaut de quatre.
Le nouveau flag “builders” permet la construction simultanée de plusieurs projets liés.

Le compilateur passe d'une exécution mono-thread à une exécution multi-thread native. Il reste possible de forcer le mode mono-thread avec un flag pour le débogage ou sur des systèmes à ressources limitées. L'augmentation des travailleurs parallèles améliore les temps de build sur de larges bases de code, au prix d'une utilisation mémoire plus élevée.

Mode watch et migration

Le mode watch a été entièrement réécrit en Go en s'inspirant de l'outil de surveillance de fichiers de Parcel.
Une migration directe vers la version 7 est recommandée depuis la version 6, tandis qu'un passage depuis la 5 nécessite une étape intermédiaire.
Les versions 6 et 7 peuvent coexister via un paquet de compatibilité.

L'absence d'API de surveillance de fichiers robuste dans la bibliothèque standard de Go a nécessité l'adaptation de solutions tierces, initialement en C++. La modernisation inclut la suppression de cibles obsolètes comme ES5 et des systèmes de modules anciens, permettant ainsi de se concentrer sur les standards actuels.

Fonctionnalités et disponibilité

Les types de littéraux de gabarit traitent désormais les émojis comme des points de code complets au lieu d'unités UTF-16.
La version stable est prévue pour le mois prochain, avec une API programmatique stable attendue pour la version 7.1.

Le changement au niveau des littéraux de gabarit corrige un problème de manipulation Unicode où les caractères étaient segmentés incorrectement. L'introduction d'un paquet de compatibilité facilite la transition entre les versions 6 et 7 pour les auteurs d'outils.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video