TypeScript Hebdo #1 : Mergify essuie les plâtres de TS 7 et tsrs explose les compteurs en Rust

📦 Actualités des versions

La dernière version stable officielle est TypeScript 7.0.2 (publiée le 2026-08-20). Cette semaine, l’équipe de VS Code a spécialement déployé la mise à jour de l’extension vscode-typescript/v1.0.1 (publiée le 2026-09-30, basée sur le commit b6eaace9).

TypeScript 7 réécrit le compilateur en Go, s’affranchissant des limites mono-thread de V8. La version 7.0.2 apporte les évolutions suivantes :

1. Vérification parallèle multi-cœurs : L’exécution de tsc --noEmit sur des machines multi-cœurs réduit considérablement les temps de compilation des volumineuses bases de code.
2. Absence temporaire de l’API de compilation : [email protected] n’expose pas encore d’API Node.js pour les bibliothèques tierces, provoquant des erreurs dans les outils reposant sur l’analyse d’AST.

Article détaillé de notre site en lien avec cette section : /lang/2026-08-20-typescript-7-0-release/

📝 Analyses approfondies

1. Retour d’expérience sur la migration de Mergify : vérification des types réduite à 3,5 secondes

Que s’est-il passé : L’équipe de Mergify a migré son application React de 244 000 lignes vers TypeScript 7.0. Sur un MacBook Pro M5, le contrôle complet est passé de 13 secondes à 3,5 secondes, tandis que le pic de consommation mémoire a chuté de 183 MiB à 101 MiB. Pourquoi c’est important : Sur un seul cœur, la version Go n’apporte qu’un gain de 1,4x par rapport à V8 ; le reste de l’accélération découle entièrement de la concurrence sur 4 cœurs. En revanche, le retrait de l’API de compilation dans la version 7.0 fait planter typescript-eslint dès son initialisation. Qui est concerné : Les équipes frontend envisageant une mise à niveau. La solution actuelle repose sur un système à « double compilateur » : via des alias de paquets, import 'typescript' renvoie à la version 6.0.2 pour ESLint en local, tandis que la 7.0 est appelée dans les pipelines CI pour une vérification ultra-rapide. L’avis de l’auteur : L’absence d’API résulte d’un arbitrage stratégique assumé. La version 7.1 promettant le rétablissement des liaisons d’API, cette configuration d’alias n’est qu’un pansement temporaire valable quelques mois ; évitez absolument d’y encapsuler des macros de compilation.

2. Le portage communautaire tsrs en Rust surpasse l’implémentation officielle en Go

Que s’est-il passé : Max Schwenk a publié en open source tsrs, qui transpose en Rust le code Go de TypeScript 7 (tsc/internal) signature par signature. Il valide avec succès 13 458 tests de diagnostics d’erreurs sur 13 462. Pourquoi c’est important : Le projet intègre son propre serveur de langage (tsrs --lsp -stdio). Lors d’un test portant sur 200 modifications dans un projet de 38 000 fichiers, la mémoire du serveur officiel en Go oscillait entre 4,9 GiB et 7,4 GiB, tandis que tsrs se maintenait de façon stable à 2,9 GiB. Qui est concerné : Les équipes d’infrastructure exécutant des serveurs de types dans des conteneurs WebAssembly, ainsi que les ingénieurs développant des chaînes d’outils complètes en Rust comme Rolldown. L’avis de l’auteur : Le ramasse-miettes (GC) de Go a tendance à gonfler l’empreinte mémoire lors de l’autocomplétion intensive et de l’instanciation de nœuds AST. La structure arborescente de Rust régie par des durées de vie prévient les fuites de mémoire au sein des processus LSP longue durée.

3. Tarve : un framework de bureau TSX natif affranchi du DOM de navigateur

Que s’est-il passé : Tarve vient de sortir, permettant de concevoir des applications natives de bureau avec Bun et du pur TSX. Le framework supprime toute dépendance à Chromium et mappe directement l’arbre des composants sur les descripteurs graphiques du système d’exploitation. Pourquoi c’est important : Tarve confie la mise en page à Taffy en Rust (prenant en charge Flexbox et CSS Grid) et le façonnage de texte à Parley. Sous Windows, il dialogue directement avec D3D11 et DXGI, avec un repli logiciel sur le rendu CPU en l’absence de GPU. Qui est concerné : Les développeurs full-stack créant des outils de bureau légers et économes en mémoire. L’avis de l’auteur : Contrairement à Tauri qui délègue la présentation à WebKit, Tarve pilote directement son propre pipeline de rendu au cœur du processus Bun. Lors des animations, il maîtrise les cycles de rafraîchissement avec un coût de communication inter-processus (IPC) infime.

4. Générateur d’expressions régulières fortement typé : composition en chaîne inspirée d’Emacs

Que s’est-il passé : Une bibliothèque de construction d’expressions régulières en TypeScript, inspirée de la macro Rx d’Emacs, a vu le jour. Elle permet de troquer les chaînes en dur contre des fonctions composables et lisibles telles que seq(start, oneOrMore(word), end). Pourquoi c’est important : Les vérificateurs statiques de types ne détectent pas les fautes d’échappement dans les regex classiques. En maintenant un AST grâce à l’inférence de types de chaînes littérales, cette bibliothèque anticipe la validation syntaxique dès la compilation. Qui est concerné : Les ingénieurs applicatifs chargés de formulaires complexes et d’analyseurs de logs. L’avis de l’auteur : Comparée à magic-regexp, cette bibliothèque délègue l’échappement aux nœuds Literal sous-jacents. Les variables injectées dynamiquement sont obligatoirement converties en texte brut, écartant ainsi tout risque de vulnérabilité ReDoS au niveau syntaxique.

🔥 Dans la communauté

1. Ask HN : Avec un backend Node, React Native ou Flutter pour le mobile ?

• Engouement : 15 commentaires, 5 votes
• Points de friction : Face à un backend sous Node.js, le dilemme oppose les partisans de « l’isomorphisme de langage » à ceux du « moteur de rendu autonome ». Les adeptes de React Native mettent en avant le partage direct des modèles de données Zod entre frontend et backend, réduisant considérablement le coût d’intégration. Les partisans de Flutter affirment que la fidélité graphique au pixel près offerte par le moteur sur les deux plateformes compense largement la contrainte de resynchroniser les modèles de données.

2. Show HN : Durable Actor Session Protocol (DASP)

• Engouement : 7 commentaires, 18 votes
• Points de friction : Avec l’essor des Cloudflare Durable Objects, la communauté s’interroge sur l’architecture limite des agents persistants. La question clé : un Actor résidant en mémoire doit-il impérativement être précédé d’un ordonnanceur sandboxé avant de traiter des requêtes publiques ? Les architectes rappellent qu’exposer directement des ports expose à des attaques par épuisement de ressources ; DASP propose d’instaurer une négociation standardisée au niveau de la couche d’analyse pour bloquer les renouvellements abusifs de session.

À surveiller la semaine prochaine

Il faudra surveiller de près les builds nightly de [email protected], en particulier pour vérifier si la restauration des signatures d’API internes n’entraîne pas une rupture brutale avec la série 6.0 pour mimer l’agencement mémoire de Go. En cas de refonte majeure des signatures, les plugins ESLint et macros Babel existants basés sur la transformation d’AST devront faire l’objet d’une réécriture approfondie.