Le compilateur TypeScript a désormais une version écrite en Rust. Cloudflare a présenté le 20 octobre 2026 tsrs, un portage expérimental du vérificateur de types, incubé dans la chaîne d’outils JavaScript Oxc avec VoidZero. La promesse affichée est forte, mais il s’agit d’une préversion : elle s’essaie sur un projet, elle ne remplace pas encore tsc dans une intégration continue.
npm install tsrs et existe aussi en WebAssembly (@tsrs/wasm).Plan de l'article
Qu’est-ce que tsrs, exactement ? #
tsrs reprend le travail du compilateur officiel, c’est-à-dire l’analyse du code et la vérification des types, mais réécrit en Rust. Dans son billet d’annonce, Cloudflare explique travailler avec VoidZero, la société derrière Vite et Oxc, et avec Max Schwenk, de l’éditeur de logiciels pour restaurants Owner.com, qui a lancé le projet.
À lire Python 3.15.1, 3.14.9 et 3.13.17 : pourquoi il faut mettre à jour pip après l’affaire eMudhra
Le point de départ est très concret. Selon RuntimeWire, la vérification des types d’une grosse base de code TypeScript coûtait si cher chez Owner.com qu’elle limitait le nombre d’agents de code que les équipes pouvaient faire tourner en même temps. Quand chaque agent relance tsc après chaque modification, la vitesse du compilateur devient un plafond de production.
Pourquoi un deuxième portage, après la version Go ? #
Microsoft a déjà fait le grand saut : TypeScript 7 repose sur un compilateur natif écrit en Go, que le billet de Cloudflare crédite d’un gain d’environ dix fois par rapport à l’ancienne version en JavaScript. Cloudflare présente ce portage comme le seul qui avait réussi jusqu’ici, et tsrs part de cette base.
L’argument avancé pour Rust tient surtout à la mémoire et au WebAssembly. Go doit embarquer son ramasse-miettes lorsqu’il est compilé en Wasm, ce qui alourdit le binaire. Rust n’a pas ce poids. Pour Cloudflare, dont les Workers exécutent du code dans des bacs à sable, pouvoir lancer un vérificateur de types complet dans un navigateur ou une sandbox est un vrai enjeu.
Que valent les chiffres annoncés ? #
Cloudflare annonce que tsrs est jusqu’à 8 fois plus rapide et consomme environ 70 % de mémoire en moins que TypeScript 7.0, avec le même nombre de workers de vérification. Le billet précise aussi que TypeScript 7.1 bêta est lui-même jusqu’à 2,5 fois plus rapide que la 7.0 : l’écart réel dépend donc de la version de référence.
À lire Next.js : deux failles critiques corrigées, passer en 16.4.1 ou 15.5.28
Ces mesures viennent de l’éditeur et portent sur les projets du dossier de benchmarks du dépôt. RuntimeWire rappelle d’ailleurs qu’il s’agit de résultats publiés par l’entreprise. Le seul test qui compte, c’est celui de votre propre monorepo : temps de vérification à froid, puis en mode incrémental, et pic de mémoire.
Peut-on l’utiliser en production ? #
Pas encore. Cloudflare parle lui-même d’une version expérimentale et reconnaît des écarts avec le TypeScript officiel, par exemple l’ordre d’affichage des diagnostics. L’objectif est de les réduire avant une version stable.
Pour une équipe, l’usage raisonnable aujourd’hui ressemble à ceci : lancer npx tsrs en parallèle de tsc sur une branche, comparer la liste des erreurs, et mesurer le gain. Si les deux sorties concordent sur votre code, tsrs peut servir de vérification rapide en local ou pour des agents, tandis que le compilateur officiel reste la référence dans la CI.
Le cas du serveur de langage
tsrs ne couvre pas encore tout. Le service de langage, celui qui alimente l’autocomplétion et les erreurs dans l’éditeur, figure dans la feuille de route. Cloudflare prévoit de fusionner tsrs avec tsc-rs, un autre portage en Rust mené avec Theo Browne, pour obtenir un seul paquet qui gère aussi le LSP.
Le risque de dérive est-il réel ? #
C’est la vraie question pour un outil de ce type. Un vérificateur de types qui accepte du code que le compilateur officiel refuse, ou l’inverse, crée de la confusion dans une équipe. Cloudflare insiste : il ne s’agit pas d’un fork, l’équipe TypeScript garde le contrôle du langage et tsrs doit suivre ses décisions.
Pour rester synchronisé, le projet compte sur un processus piloté par des agents, comparable à celui utilisé pour Vinext, avec une vigilance annoncée sur les divergences. Cloudflare dit aussi vouloir reverser des optimisations au code Go de TypeScript. The New Stack résume ce positionnement par la phrase de l’annonce : « We are not forking TypeScript ».
Ce que cela change pour un développeur web #
À court terme, rien d’obligatoire. TypeScript 7 reste la version de référence et la plupart des projets y ont déjà gagné en vitesse. tsrs intéresse d’abord trois profils : les grosses bases de code où la vérification prend plusieurs minutes, les équipes qui multiplient les agents de code, et ceux qui veulent vérifier des types dans un navigateur ou un environnement Wasm.
À moyen terme, l’intégration dans Oxc est la piste à suivre. Cloudflare évoque des règles Oxlint capables d’utiliser les types, ce qui rapprocherait le linter et le compilateur dans un seul outil natif. Pour un développeur qui se forme, c’est un bon signal : comprendre la différence entre transpiler, vérifier et linter devient plus utile que jamais.
Questions fréquentes #
tsrs remplace-t-il TypeScript ?
Non. tsrs est une autre implémentation du même compilateur. Le langage, sa syntaxe et ses règles restent décidés par l’équipe TypeScript.
Comment l’essayer ?
Le billet de Cloudflare indique npm install tsrs puis npx tsrs. Une version WebAssembly est publiée sous le nom @tsrs/wasm.
Faut-il l’adopter dans la CI ?
Pas à ce stade. Le projet est expérimental et ses diagnostics diffèrent encore de l’officiel sur certains points. Mieux vaut le comparer à tsc avant de s’y fier.
