TypeScript Hebdo n° 3 : Bun intègre un vérificateur de types, ts-rust surpasse Go et ttsc réinvente le linting à la compilation

📦 Actualités des versions

Évolution des versions stables et modernisation de la chaîne de compilation

La dernière version stable officielle demeure TypeScript 7.0.2 (publiée le 20 août 2026). Au cours des sept derniers jours, l’équipe officielle n’a publié aucun nouveau correctif pour le compilateur. L’extension d’éditeur vscode-typescript/v1.0.1, publiée le 30 septembre, intègre d’office cette version du compilateur. Pour un tour d’horizon complet des changements architecturaux de la branche 7.0, consultez notre dossier : TypeScript 7.0 : analyse des nouveautés.

Au sein de l’actuelle série 7.0, les ajustements structurels essentiels et leurs conséquences concrètes en ingénierie se résument ainsi :

Changement	Règle modifiée	Impact opérationnel en ingénierie
Vérification concurrente sous architecture Go	Migration du compilateur de JS vers Go avec ajout du paramètre --checkers pour gérer le nombre de threads de travail (valeur par défaut : 4).	Les builds complets sur machines de développement multicœurs sont 8 à 12 fois plus rapides ; dans les conteneurs CI aux ressources restreintes, il est nécessaire de borner ce paramètre pour prévenir la saturation mémoire.
Absence provisoire de la Programmatic API	TS 7.0 est distribué exclusivement sous forme de binaire CLI natif et n’expose aucune API de compilation Node.js appelable de l’extérieur.	Les outils reposant sur le contexte interne de l’AST (comme typescript-eslint) ne peuvent pas s’intégrer directement et exigent l’alias @typescript/typescript6 pour des builds hybrides.
Mode strict généralisé par défaut	Activation par défaut de strict et rootDir: "./" ; suppression de baseUrl et moduleResolution: node, avec fin du support de target: es5.	Les projets existants doivent purger leurs configurations obsolètes lors de la mise à niveau ; la résolution des alias de chemin doit basculer vers les normes nodenext ou bundler.

En matière de compatibilité de plateformes, les binaires de TS 7.0 couvrent les principales architectures Linux, macOS et Windows. L’absence de liaisons C++ natives complique toutefois l’exécution du vérificateur au sein de conteneurs WebAssembly.

📝 Analyses approfondies

La PR #44361 de Bun introduit le vérificateur de types natif bun check

Que s’est-il passé ? : Jarred Sumner a soumis la PR #44361 pour Bun, portant le noyau de typescript-go 7.0.2 afin d’ajouter un vérificateur de types natif représentant environ 150 000 lignes de nouveau code. Elle introduit la commande bun check ainsi que le drapeau associé --check. Lors de tests menés sur un projet Next.js (2 881 fichiers sources), le temps CPU pour une vérification intégrale est passé de 6,9 secondes avec tsc 7.0.2 à 2,4 secondes, tandis que le pic de mémoire vive chutait de 1,78 Go à 0,69 Go.

Pourquoi c’est important : Auparavant, les environnements d’exécution légers se contentaient d’effacer les types sans contrôle sémantique. Bun intègre désormais la vérification de types au sein d’un processus unique et résout l’analyse des dépendances de Project References en mémoire vive. Validée sur 72 projets open source majeurs (1 103 configurations) et 13 000 cas de test officiels, cette implémentation atteint un taux de conformité de 99,99 % et élimine les dérives sporadiques de numéros de lignes observées dans le Go officiel lors de situations de concurrence multithread.

Qui est concerné ? : Les ingénieurs front-end et système orchestrant des microservices, des frameworks full-stack ou des suites de tests locales avec Bun. Les pipelines de CI peuvent désormais supprimer leurs conteneurs Node.js dédiés au typechecking.

Lien : Bun PR #44361: bun check builtin type checker

L’avis de la rédaction : L’intégration du vérificateur de types directement dans le runtime constitue une évolution naturelle pour les environnements modernes. Le pic de consommation mesuré à 0,69 Go écarte tout risque d’OOM en conteneur. En revanche, comme elle ne génère ni fichiers .d.ts ni SourceMaps, la publication officielle de bibliothèques doit toujours s’appuyer sur la chaîne de compilation classique.

Arrivée de ts-rust (tsc-rs) : deux semaines de LLM pour porter TS 7 en Rust et tripler la vitesse de Go

Que s’est-il passé ? : Theo Browne a publié en open source pingdotgg/ts-rust (npm : tsc-rs), portant le compilateur officiel en Go vers Rust à partir du commit 673a5f17d713 de TS 7.1-dev. Une première tentative via des modèles OpenAI a consommé pour 400 000 dollars de tokens sur 1,3 million de lignes de code, mais s’est heurtée à un plafond de compatibilité de 84 %. Le projet a ensuite été intégralement repris à zéro par Claude Opus 5.5 en deux semaines pour 24 000 dollars de tokens. Sur le benchmark T3 Code, tsc-rs affiche 5,27 secondes d’exécution, se révélant 3,05 fois plus rapide que le tsc 7 officiel en Go (16,10 secondes) et 11,9 fois plus rapide que tsc 6 (62,63 secondes).

Pourquoi c’est important : Le projet réussit l’ensemble des 181 711 cas de test officiels de transpilage et d’erreurs, tout en fournissant des diagnostics rigoureusement identiques sur 120 bibliothèques open source réelles. Il intègre nativement les règles de diagnostic pour Effect 4 (plage 377xxx) sans nécessiter de plugins secondaires. L’architecture Rust dépourvue de ramasse-miettes ouvre la voie à une exécution fluide du vérificateur en WebAssembly. Dan Rosenwasser, responsable de TypeScript chez Microsoft, est intervenu sur Hacker News pour confirmer que l’équipe suivait ces travaux de près.

Qui est concerné ? : Les architectes web préparant l’analyse de types in-browser via WASM, les concepteurs d’outils basés sur Rolldown ou Rspack, et les équipes utilisant l’écosystème Effect.

Lien : ts-rust: An experimental Rust port of TypeScript 7 compiler

L’avis de la rédaction : L’efficacité des modèles de langage avancés pour la conversion mécanique d’arbres syntaxiques est indéniable. Néanmoins, une base de code générée automatiquement manque souvent de la structuration architecturale qu’apporterait une équipe humaine. Si Microsoft venait à modifier les frontières d’inférence de types, la maintenance pourrait imposer de lourdes et coûteuses campagnes de régénération par tokens.

ttsc : moteur de plugins et de linting intégré au compilateur fondé sur l’architecture typescript-go

Que s’est-il passé ? : L’auteur de Typia, Samchon, a mis en ligne la chaîne d’outils ttsc, accompagnée du runtime de pré-vérification ttsx et de @ttsc/lint. Conçu directement sur l’architecture typescript-go de Microsoft, le projet rétablit la prise en charge des plugins de transformation AST supprimée dans TS 7.0, permettant d’exécuter des vérifications de règles de code au cours de la même passe d’inférence de types.

Pourquoi c’est important : La disparition des API Node.js dans TS 7 bloquait la mise à niveau de bibliothèques dépendantes de macros à la compilation et de métadonnées de types (comme Typia ou TS-Patch). ttsc injecte un middleware directement pendant l’analyse du compilateur, préservant ainsi la réflexivité des types. Son moteur @ttsc/lint intègre plus de 720 règles et affiche un débit jusqu’à 900 fois supérieur à celui d’ESLint sur des projets de l’envergure de VS Code. De plus, l’outil compagnon @ttsc/graph réduit de 92 % la consommation de tokens lors de l’analyse structurelle des projets par des agents IA.

Qui est concerné ? : Les équipes concevant des architectures backend critiques tributaires du typage statique, les mainteneurs de grands monorépôts et les développeurs souhaitant regrouper le linting et le typechecking dans la CI.

Lien : samchon/ttsc: A typescript-go toolchain for compiler plugins

L’avis de la rédaction : Avancer le contrôle des règles de linting dans l’étape de validation des types accélère notablement les chaînes de CI. En revanche, lier étroitement le formatage et le style de code au cœur du compilateur contraint à renoncer à certains plugins AST externes hautement spécialisés, un coût de transition qui mérite mûre réflexion.

🔥 Discussions de la communauté

Un compilateur réécrit par des LLM déclenche un vif débat de performances entre Rust et Go

Le 8 octobre, le projet pingdotgg/ts-rust a suscité des échanges techniques approfondis sur Hacker News (117 points, 222 commentaires).

• Partisans de la performance pure sans ramasse-miettes : les défenseurs de Rust ont souligné que le contrôle des types dans TypeScript implique des types unions profondément imbriqués et des types conditionnels complexes, dont la prolifération éphémère de nœuds AST perturbe le ramasse-miettes de Go. Sur des démons LSP de longue durée, la consommation mémoire de la version Go est passée de 4,9 Go à 7,4 Go, tandis que la version Rust demeurait stable à 2,9 Go grâce à des allocateurs d’arène et une gestion déterministe de la mémoire. De plus, la compilation WASM compacte fait de Rust le candidat idéal pour les IDE dans le navigateur.
• Partisans de la maintenabilité et partisans du respect des spécifications : des ingénieurs plus réservés ont rappelé que TypeScript ne dispose d’aucune spécification formelle de grammaire et que le standard de facto demeure l’implémentation officielle du compilateur. Microsoft a choisi Go pour sa syntaxe directe, garantissant une proximité logique avec le code d’origine en JS/TS. Des centaines de milliers de lignes de code produites par IA sans audit humain minutieux risquent de devenir des boîtes noires face aux cas limites non documentés, excédant à terme les gains initiaux apportés par la machine.

Lien : HN: Port of the TypeScript compiler, checker and lsp to Rust, by LLM

Une équipe confie 60 PRs consécutives à l’IA : le système de types à l’épreuve de la « boursouflure de types »

Sur Reddit r/typescript, le fil très suivi Every PR on my team is written by AI now (155 points, 118 commentaires) relatait le retour d’expérience d’un ingénieur de grand monorépôt dont l’équipe a fusionné près de 60 PRs générées par des agents IA, provoquant une confrontation sur l’évolution des pratiques logicielles.

• Défenseurs des gains de productivité : ils ont souligné qu’avec des garde-fous architecturaux stricts associés à des linters rigoureux et aux revues automatisées de CodeRabbit, la sûreté statique des types produite par l’IA dépasse celle de développeurs juniors ou intermédiaires. Les erreurs d’exécution liées aux pointeurs nuls ont chuté, libérant les développeurs pour la modélisation métier.
• Mise en garde contre la dislocation de la cohérence globale : plusieurs architectes expérimentés ont alerté sur la propension des agents IA à générer localement des structures de données redondantes faute de vue d’ensemble transversale. Cela favorise l’apparition de types dupliqués aux variantes minimes (comme trois déclarations distinctes de User pour une même entité). Le système de types cesse d’être un modèle mental du domaine pour devenir un simple mécanisme de validation ponctuelle, risquant à long terme d’alourdir l’analyse topologique des types lors des builds.

Lien : Reddit: Every PR on my team is written by AI now

L’équipe Deno rejoint Cloudflare et annonce la fin de son environnement autonome d’ici un an

Le 9 octobre, Ryan Dahl a annoncé le rachat de l’équipe Deno par Cloudflare. L’environnement d’exécution autonome de Deno continuera d’être maintenu pendant un an avant d’achever son cycle d’évolution indépendant, une annonce qui a provoqué une onde de choc sur r/typescript (542 points, 96 commentaires).

• Le pragmatisme des réalités économiques : de nombreux développeurs ont reconnu le plafond de verre commercial des environnements d’exécution indépendants. Bien que Deno ait été pionnier dans la prise en charge sans configuration de TypeScript, les imports de modules par URL et la sécurité par bac à sable, la force d’inertie de l’écosystème npm et les investissements massifs requis pour l’infrastructure cloud rendaient la concurrence intenable face aux géants du cloud.
• L’hommage à l’héritage technique : d’autres observateurs estiment que Deno a accompli sa mission historique. Ses briques fondamentales comme rusty_v8 et la standardisation des Web API s’intégreront directement à l’infrastructure edge mondiale workerd de Cloudflare, tandis que son combat pour intégrer nativement TypeScript a durablement transformé tous les environnements d’exécution modernes.

Lien : Reddit: Deno is dead, Deno Blog: Joining Cloudflare

🔭 À surveiller la semaine prochaine

• RFC de la Programmatic API de TypeScript 7.1 : suivi régulier des débats de conception sur GitHub quant à la restauration des signatures d’API Node.js du compilateur, et examen d’un éventuel recours à une couche intermédiaire FFI ;
• Validation Canary en production pour Bun check : surveillance des publications de versions consécutives à la fusion de la PR #44361 dans la branche principale de Bun, en portant attention à la stabilité mémoire et à la finesse des diagnostics au sein des grands monorépôts.