Mardi 20 octobre 2026, un billet du blog de Cloudflare a fait grimper un fil Hacker News à 389 points et 191 commentaires en quelques heures. Le sujet : tsrs, un compilateur TypeScript réécrit en Rust. Pour qui attend devant son terminal que le type-check finisse, la promesse est limpide. Un vérificateur de types ne compile rien, mais il relit tout le code à chaque sauvegarde, et c'est de lui que dépend le temps d'attente, parfois une quarantaine de secondes sur un gros dépôt.
Un portage « en concertation », pas un fork
Cloudflare et VoidZero présentent tsrs avec Max Schwenk (Owner.com), en concertation avec l'équipe TypeScript. Le projet est incubé dans l'écosystème Oxc. Ce n'est pas un fork : Cloudflare l'écrit noir sur blanc, l'équipe TypeScript reste responsable du langage et tsrs doit suivre ses décisions, y compris les plus lentes.
8× contre TypeScript 7.0 : lire la ligne de référence
Les chiffres annoncés : jusqu'à 8× plus rapide et environ 70 % de mémoire en moins que TypeScript 7.0, à nombre de workers identique. La comparaison a été calibrée avec l'équipe TypeScript, ce qui évite le classique benchmark qui change de machine ou d'options en cours de route.
Le calendrier brouille pourtant la lecture. TypeScript 7.1 bêta est déjà jusqu'à 2,5× plus rapide que la 7.0, et une partie de ces optimisations vient de tsrs. Autrement dit, l'écart avec la version que l'on installera dans six mois sera plus étroit que 8×. Quant aux 70 %, ils valent pour un réglage précis : la configuration par défaut de tsrs est adaptative et consomme plus de mémoire pour aller plus vite.
Le « jusqu'à 8× » compare tsrs à TypeScript 7.0. La version que votre CI installera dans six mois, elle, bouge déjà.
Le portage par IA, argument et angle mort
Pourquoi maintenant ? Cloudflare avance que les modèles d'IA de pointe savent désormais réaliser des portages à grande échelle en quelques jours. L'argument est repris tel quel dans le billet, et il mérite d'être discuté : écrire un compilateur dans un autre langage devient bon marché, mais comprendre pourquoi l'original se comporte ainsi ne l'est pas. Le code se génère, le jugement sur les cas limites reste humain. Et on a déjà vu fleurir des « slopforks », ces portages bâclés qui ressemblent à l'original jusqu'au premier cas tordu.
Le dispositif de maintenance, hérité de Vinext, leur portage de Next.js, est ingénieux : chaque matin, un agent lit les changements amont et ouvre des tickets ; chaque nuit, la suite de tests de TypeScript tourne contre le portage. La matrice de compatibilité qui en sort dit ce qui est testé. Elle ne dit rien de ce que la suite ne couvre pas.
Pre-commit, monorepos, Wasm : qui sentira la différence
Tant qu'un type-check complet coûte quarante secondes, on le laisse à la CI (intégration continue) et on accepte de pousser du code non vérifié. Ramené à cinq secondes, il redevient envisageable en pre-commit. Ces deux durées sont ici une hypothèse de travail : le billet ne les attribue pas à un projet nommé, d'où l'intérêt de chronométrer son propre dépôt avant de s'enthousiasmer.
Le bénéfice est surtout pour les gros monorepos, les équipes qui génèrent leurs types, celles dont la CI se facture à la minute. Rust ouvre aussi la porte à WebAssembly (Wasm), donc à un vérificateur qui tourne dans un navigateur ou une sandbox. Sur un site de quelques milliers de lignes, personne ne verra rien.
Deux compilateurs, une seule définition du langage
tsrs est une version expérimentale. La conformité visée est de 100 %, elle n'est pas atteinte, et des différences se voient déjà : l'ordre des diagnostics n'est pas le même que celui de tsc. Un type-check rapide qui ne signale pas la même erreur au même endroit ne remplace pas tsc, il s'ajoute à lui.
L'implémentation officielle reste celle de l'équipe TypeScript, écrite en Go. Quand deux compilateurs divergent, la vitesse ne tranche rien : seule compte l'instance qui a le dernier mot. Sur ce point, la position de Cloudflare est la bonne, tsrs suit et ne dicte pas. Mais un projet financé par des acteurs de cette taille, qui renvoie déjà ses optimisations vers l'amont, pèsera tôt ou tard sur le calendrier du langage. C'est à surveiller autant que les benchmarks.
Avant d'installer quoi que ce soit
Premier réflexe : mesurer le temps mural de son propre tsc, pas le temps CPU, sur le dépôt réel. Ensuite, tester tsrs sur une branche en comparant le nombre et la nature des diagnostics, pas seulement la durée.
- Pas de CI bloquante tant qu'il n'existe ni version stable ni liste publique des divergences.
- tsc reste la source de vérité ; tsrs sert de second avis rapide.
- Le Language Server Protocol (LSP), qui alimente l'éditeur, est l'endroit où le gain se sentira au quotidien, plus que dans un log de CI.
On ne sait pas encore si ce second compilateur natif s'installera comme produit ou s'il sera absorbé par l'officiel, comme l'ont déjà été certaines de ses optimisations.