Des builds plus rapides, un IDE plus réactif, le "strict" activé par défaut... Microsoft est en train de finaliser son TypeScript 7.0 (en open source) doté d'un nouveau compilateur natif!

Dev

Microsoft peaufine TypeScript 7.0 avant sa sortie prochaine

Par Laurent Delattre, publié le 16 janvier 2026

Le langage TypeScript (en open source) s’apprête à connaître sa plus grande transformation depuis sa création. Microsoft vient de dévoiler les avancées de « projet Corsa », nom de code de TypeScript 7.0, qui marque un tournant radical : le compilateur abandonne sa base JavaScript historique pour une réécriture complète en Go. Une révolution technique qui promet des gains de performance spectaculaires.

TypeScript est né d’un constat pragmatique. Au début des années 2010, JavaScript dominait déjà le développement web, mais le langage montrait ses limites dès qu’il s’agissait de développer des applications d’envergure. Anders Hejlsberg, architecte en chef chez Microsoft et créateur de C# et Delphi, a dirigé une équipe chargée de résoudre ce problème. Comme il l’explique : « Il n’y avait pas de classes, pas de modules, pas de système de typage statique. Écrire de grandes applications en JavaScript était très difficile. Les outils disponibles à l’époque étaient vraiment mauvais. On avait l’impression de coder dans le Bloc-notes. » Sans compter que la maintenance des codes sources étaient des plus compliquées, le langage JavaScript manquant de rigueur et de contrôle.

Rendu public en octobre 2012, TypeScript a immédiatement apporté une réponse élégante au défi des grands développements JavaScript. Conçu comme un sur-ensemble de JavaScript, il y ajoute le typage statique optionnel, les classes, les interfaces et les modules, tout en restant parfaitement compatible avec l’écosystème JavaScript existant. Le code TypeScript se compile (ou plus précisément se transpile) en JavaScript standard, exécutable dans n’importe quel navigateur ou environnement Node.js.

Le principe fondateur était simple mais audacieux. Anders Hejlsberg le résume ainsi : « Notre pari n’était pas de remplacer JavaScript, mais de rendre le développement JavaScript à grande échelle viable en ajoutant des types, des outils et la capacité de refactorer le code dans le langage le plus permissif du monde. »

Un succès devenu incontournable

Treize ans plus tard, le pari est largement gagné. En août 2025, TypeScript est devenu le langage le plus utilisé sur GitHub, dépassant pour la première fois Python et JavaScript. L’enquête Stack Overflow 2025 le montre, elle aussi, massivement adopté par les développeurs (43,6% des répondants déclarent l’utiliser).Le langage compte désormais plus de 2,6 millions de contributeurs actifs mensuels, soit une progression de 66 % en un an.

Cette ascension fulgurante s’explique par plusieurs facteurs. Tous les grands frameworks frontend (React, Angular, Vue, Next.js, Svelte) utilisent désormais TypeScript par défaut dans leurs projets. L’essor de l’IA générative et des assistants de code comme GitHub Copilot a également accéléré l’adoption : une étude académique de 2025 révèle que 94 % des erreurs de compilation générées par les grands modèles de langage (LLM) sont des erreurs de typage, que TypeScript détecte automatiquement avant l’exécution.

La grande nouveauté : un compilateur natif écrit en Go

Jusqu’à présent, TypeScript présentait une particularité : son compilateur était lui-même écrit en TypeScript/JavaScript. Cette approche dite « self-hosted » garantissait portabilité et facilité de contribution. Mais TypeScript 7.0 va rompre avec cette tradition.
Il est temps pour le langage de s’envoler vers de nouveaux horizons de performance.

Ainsi, la nouveauté centrale de TypeScript 7.0 tient en un mot : natif. Microsoft (avec “Project Corsa”) est en train de porter le compilateur et le language service en code natif. Avec à la clé un triple objectif : plus de performance brute, moins de mémoire consommée, et surtout plus de parallélisme.

Une petite précision s’impose ici. L’idée de Microsoft n’est absolument pas de « compiler JavaScript en code machine » et donc de produire du code directement exécutable pour les programmes écrits en TypeScript. Le nouveau compilateur produit comme précédemment du code JavaScript en sortie. L’objectif est bien en revanche d’exécuter l’outil de compilation/transformation sous forme de binaire performant, alors que l’ancien compilateur écrit en TypeScript/JavaScript nécessitait une VM JavaScript.

Ce nouveau compilateur, baptisé tsgo, est entièrement réécrit en langage « Go » et peut cohabiter avec l’ancien compilateur « tsc ». Et les résultats sont spectaculaires : les temps de compilation sont jusqu’à 10 fois plus rapides, avec une consommation mémoire réduite et une exploitation du parallélisme natif.

Anders Hejlsberg explique ce choix : « Le gain de performance est de 10x. La moitié vient du passage au code natif, l’autre moitié de la concurrence en mémoire partagée. On ne peut pas ignorer un facteur 10. » Et de préciser : « Nous avons expérimenté avec C#, avec d’autres langages, et nous avons finalement choisi Go. »

L’approche singulière de Microsoft

On peut ici se demander pourquoi Microsoft n’a pas envisager d’intégrer un outil de compilation native de JavaScript (voir encadré) et pourquoi le choix d’intégralement réécrire son compilateur en Go ?

Plusieurs raisons expliquent cette décision. D’abord, la vérification de types : contrairement à des compilateurs JavaScript comme esbuild ou SWC qui se concentrent sur la transpilation rapide sans vérification de types, TypeScript doit garantir une analyse sémantique complète et fidèle à l’existant.
Ensuite, la compatibilité : Microsoft s’engage à produire un compilateur « fonctionnellement identique » à l’ancien, jusque dans ses comportements les plus subtils. Le point clef n’est pas de réinventer TypeScript : c’est d’industrialiser un portage en gardant une compatibilité élevée, y compris en structure de code, car Microsoft s’attend à maintenir deux codebases en parallèle un certain temps. Dans leurs mots, l’objectif est de rester “aussi compatible que possible” et de faciliter le passage de changements d’une base à l’autre.

Le choix de Go plutôt que Rust, l’autre candidat sérieux, s’explique par plusieurs facteurs documentés par l’équipe : Go offre un ramasse-miettes (Garbage Collector) automatique tout en restant un langage « natif d’abord », et la base de code TypeScript existante utilise un style très fonctionnel avec peu de classes, ce qui correspond bien aux structures de données et fonctions de Go.

Les autres nouveautés de TypeScript 7.0

Au-delà de la réécriture du compilateur, TypeScript 7.0 apporte plusieurs changements significatifs. L’arrivée du compilateur natif s’accompagne d’un second mouvement : réduire l’héritage et rendre l’expérience par défaut plus stricte, plus moderne, plus alignée sur les runtimes actuels.

Le mode strict activé par défaut. C’est probablement le changement le plus visible pour les développeurs. Jusqu’ici, le mode strict devait être explicitement activé. Désormais, il sera la configuration par défaut.

Suppression de fonctionnalités obsolètes. TypeScript 7.0 retire plusieurs options dépréciées : –target es5 disparaît (ES2015 devient la cible minimale), –baseUrl est supprimé, et –moduleResolution node10 laisse place à bundler et nodenext.

Support du Language Server Protocol (LSP). TypeScript 7.0 abandonne le protocole TSServer propriétaire au profit du standard LSP. Cette évolution ouvre la porte à une meilleure intégration avec tous les éditeurs de code, au-delà de Visual Studio Code.

Service de langage repensé. L’extension native preview pour VS Code est d’ores et déjà disponible et intègre l’auto-complétion (y compris les auto-imports), la navigation vers les définitions, le renommage, la recherche de références et le formatage. L’équipe a également revu l’architecture pour améliorer la stabilité et exploiter le parallélisme.

Enfin, un point qui parlera aux équipes outillage : la compatibilité API est un sujet à part entière. Microsoft indique que TypeScript 7.0 ne supporte pas l’API historique “Strada” et qu’une nouvelle API “Corsa” est en construction ; autrement dit, les outils qui s’adossent profondément au compilateur devront planifier une migration.

Disponibilité et migration

Les développeurs peuvent d’ores et déjà tester TypeScript 7.0 et Microsoft assure que l’outil est déjà très utilisable et stable. L’extension Visual Studio Code est également disponible sur le marketplace et mise à jour quotidiennement.

Autre information utile, il n’aura pas échappé aux DSI que la dernière version en date de TypeScript est la « 5.9 ». Alors pourquoi « 7.0 » et quid de « 6.0 » ?

Et bien il y aura bien une version TypeScript 6.0. Elle devrait sortir à peine avant la disponibilité de TypeScript 7.0 dans les semaines à venir. TypeScript 6.0, sera la dernière version avec un compilateur écrit en JavaScript et servira de version de transition. Il ne devrait jamais y avoir de version 6.1 : Les mises à jour de maintenance de la version 6.0 seront limitées aux correctifs de sécurité et aux régressions critiques.

L’équipe Microsoft a également publié un outil de migration, ts5to6, pour aider les projets à adapter leur configuration tsconfig.json aux nouvelles exigences et à préparer le terrain pour TypeScript 7.0.

Microsoft n’a pas communiqué de date précise pour la sortie finale de TypeScript 7.0, mais l’état d’avancement du projet et la stabilité des previews suggèrent une disponibilité dans les prochaines semaines. L’équipe encourage les développeurs à tester dès maintenant les versions preview et à signaler tout problème sur le dépôt GitHub du projet.

La réécriture de TypeScript en Go représente un investissement technique considérable, mais elle témoigne de la volonté de Microsoft de pérenniser un langage devenu central dans l’écosystème du développement moderne. À l’heure où l’IA transforme les pratiques de programmation, disposer d’un compilateur rapide et d’un système de types robuste n’a jamais été aussi stratégique.


La compilation native de JavaScript : un terrain déjà balisé

Seuls le compilateur TypeScript est réécrit en Go pour obtenir du code natif rapide. Mais il continue de produire en sortie du JavaScript qui peut, lui aussi, si nécessaire, être recompilé en natif avec des gains de performance considérables.

Plusieurs compilateurs de JavaScript sont disponibles sur le marché :
esbuild (2020) : développé en Go par Evan Wallace, cofondateur de Figma. Cet outil de bundling et de transpilation affiche des temps de build de l’ordre de 0,33 seconde là où les solutions JavaScript nécessitent plus de 30 secondes.
SWC (Speedy Web Compiler) : écrit en Rust, il se présente comme 20 fois plus rapide que Babel sur un seul thread et 70 fois plus rapide en parallèle. SWC est utilisé par Next.js, Parcel, Deno et des entreprises comme Vercel, ByteDance ou Shopify.
Oxc : une chaîne d’outils complète en Rust qui inclut parser, linter, minifier et transformateur.
Bun : un runtime JavaScript compatible Node.js qui intègre nativement la transpilation TypeScript et affiche des performances remarquables. Bun vient d’ailleurs d’être acquis par Anthropic. Il est vrai qu’il sert de runtime à toute la mécanique interne de Claude Code !



À LIRE AUSSI :

À LIRE AUSSI :

Dans l'actualité

Verified by MonsterInsights