AngularAngular

Appearance

Vous souhaitez recevoir de l'aide sur ce sujet ? rejoignez la communauté Angular.fr sur Discord.

TypeScript 7.0 est sorti : quel impact pour Angular ? (10 juillet 2026) ​

Illustration magazine sur TypeScript 7.0 et Angular

TypeScript 7.0 est disponible depuis le 8 juillet 2026. Cette version est importante, mais pas pour la raison habituelle.

Il ne s'agit pas d'une version pleine de nouvelles syntaxes TypeScript à apprendre. Le vrai changement est plus profond : le compilateur et les outils de langage ont été portés en Go. C'est ce que Microsoft appelait jusqu'ici le port natif de TypeScript, souvent associé au nom tsgo.

Le résultat annoncé est spectaculaire : des compilations et des services d'éditeur beaucoup plus rapides, parfois autour d'un ordre de grandeur selon les projets. Mais pour Angular, la conclusion pratique est plus nuancée :

  • TypeScript 7.0 est bien sorti.
  • Angular veut bien aller vers ce nouveau compilateur.
  • Ce travail est déjà dans la roadmap Angular.
  • Mais une application Angular 22 ne peut pas simplement remplacer TypeScript 6 par TypeScript 7 et attendre que ng build fonctionne.

Voyons pourquoi.

TypeScript 7, c'est surtout une nouvelle fondation ​

Jusqu'à TypeScript 6, le compilateur TypeScript était lui-même écrit en TypeScript, puis exécuté dans un environnement JavaScript comme Node.js.

Avec TypeScript 7, Microsoft change la base technique : le compilateur, le serveur de langage et plusieurs briques internes passent sur une implémentation native en Go.

L'objectif est simple à comprendre : utiliser plus efficacement les machines modernes.

Un gros projet TypeScript ne fait pas qu'analyser un fichier après l'autre. Il doit parser du code, résoudre des imports, construire des graphes de projets, vérifier des types, produire des diagnostics, parfois générer du JavaScript et des fichiers .d.ts. TypeScript 7 peut paralléliser davantage de travail, notamment avec des options comme --checkers et --builders.

Pour un développeur, cela peut se traduire par :

  • un tsc --noEmit plus rapide ;
  • un mode --watch plus réactif ;
  • des diagnostics qui remontent plus vite dans l'éditeur ;
  • des CI moins bloquées par le type-checking ;
  • des agents de code qui itèrent plus vite parce que la boucle "modifier, vérifier, corriger" coûte moins cher.

Le retour d'expérience de VS Code donne une bonne image de cette transition : l'équipe a migré progressivement, en faisant tourner TypeScript 6 et 7 côte à côte avant de basculer davantage de workflows vers TypeScript 7.

TypeScript 6 était la marche de transition ​

Pour comprendre TypeScript 7, il faut aussi regarder TypeScript 6.

TypeScript 6 a servi de version de préparation. Certaines anciennes options ont été dépréciées ou durcies pour rapprocher les projets du comportement attendu par TypeScript 7.

Parmi les changements à surveiller :

  • strict devient le défaut ;
  • module se rapproche de esnext ;
  • target vise un ECMAScript moderne ;
  • types devient plus explicite ;
  • rootDir peut devoir être déclaré plus clairement ;
  • plusieurs vieux modes comme target: es5, moduleResolution: classic, module: amd, module: umd, module: systemjs ou baseUrl sortent du chemin moderne.

Dit autrement : TypeScript 7 n'est pas seulement "TypeScript 6 en plus rapide". Il applique aussi les décisions préparées par TypeScript 6.

Pour une application Angular moderne, beaucoup de ces choix vont dans le sens de l'écosystème actuel : ESM, bundlers, navigateurs evergreen, configuration plus explicite. Mais une base de code ancienne peut découvrir des erreurs que TypeScript 5 ou 6 laissait encore passer avec des avertissements ou des options de compatibilité.

Pourquoi Angular ne bascule pas immédiatement ​

Angular dépend fortement de TypeScript. Pas seulement parce que les applications Angular sont écrites en TypeScript.

Le compilateur Angular, ngc, s'appuie profondément sur les APIs du compilateur TypeScript. Il doit analyser les composants, lire les décorateurs, comprendre les templates, produire des diagnostics Angular, générer du code, et connecter tout cela à l'outil de build et au language service.

Cette intégration est plus profonde que celle d'un projet qui lance seulement :

bash
tsc --noEmit

C'est la raison principale du blocage actuel : TypeScript 7.0 ne fournit pas encore l'API programmatique stable dont des outils comme Angular ont besoin.

Microsoft le dit explicitement dans l'annonce de TypeScript 7.0 : les langages ou frameworks qui embarquent TypeScript dans leur propre compilateur ou service de langage, comme Angular pour le typage spécialisé des templates, ne peuvent pas encore exploiter directement TypeScript 7 de bout en bout. La recommandation temporaire est d'utiliser TypeScript 7 pour des scénarios CLI où il n'y a pas besoin de plugin ou d'API TypeScript avancée, et de continuer avec TypeScript 6 pour les outils qui dépendent encore de cette API.

Ce que dit l'équipe Angular ​

La bonne nouvelle : Angular ne semble pas ignorer TypeScript 7.

Dans la roadmap officielle, l'équipe Angular explique que Microsoft a porté TypeScript en Go avec une promesse de compilation nettement plus rapide, mais qu'Angular a une des intégrations les plus profondes avec le compilateur TypeScript. La roadmap indique que l'équipe prototype et explore le support de tsgo, avec l'objectif de livrer un compilateur Angular compatible avec ce nouveau monde.

Les issues GitHub récentes vont dans le même sens.

Dans angular/angular#69704, ouverte après la sortie de TypeScript 7.0, la demande portait sur l'élargissement de la peer dependency TypeScript d'Angular 22. La réponse de l'équipe Angular est claire : supporter TypeScript 7.0 demande un refactoring majeur du compilateur, et TypeScript 7.0 ne livre pas encore l'API stabilisée nécessaire au support complet.

Dans angular/angular#69719, la réponse est encore plus directe : la fonctionnalité est officiellement dans la roadmap et activement travaillée. Mais comme TypeScript 7 n'a pas encore les APIs nécessaires pour émettre du code Angular, une équipe dédiée construit un nouveau modèle de compilation.

Une ancienne issue, angular/angular#61634, aide à comprendre l'ampleur du sujet. L'équipe y rappelait que la plupart des dépendances à l'API TypeScript se trouvent dans packages/compiler-cli, et que le compilateur Angular est aujourd'hui construit autour d'un ts.Program.

La conclusion raisonnable est donc :

  • oui, Angular souhaite aller vers TypeScript 7 et tsgo ;
  • non, ce n'est pas un simple changement de version dans package.json ;
  • non, Angular 22 ne supporte pas officiellement TypeScript 7.0 pour ng build ;
  • le vrai support dépendra d'un nouveau modèle de compilation et des APIs TypeScript attendues côté 7.1 et au-delà.

Ce que vous pouvez faire aujourd'hui dans un projet Angular ​

Si votre projet est en Angular 22, gardez la version de TypeScript supportée par Angular pour les commandes Angular.

La matrice officielle des versions Angular reste la source de vérité. Au moment d'écrire ces lignes, Angular 22.x déclare TypeScript >=6.0 <6.1. Installer TypeScript 7 directement dans le projet risque donc de casser @angular/compiler-cli, même si TypeScript 7 fonctionne très bien sur un projet TypeScript pur.

Le chemin prudent ressemble plutôt à ceci :

  1. Migrer proprement vers TypeScript 6 si ce n'est pas déjà fait.
  2. Corriger les dépréciations TypeScript 6 au lieu de les masquer durablement.
  3. Vérifier les options target, module, moduleResolution, types, rootDir, baseUrl et les imports avec attributs.
  4. Suivre la roadmap Angular et les releases Angular avant de changer la version TypeScript utilisée par ng build.
  5. Tester TypeScript 7 séparément pour du type-checking non Angular si votre architecture le permet.

Le point 5 demande de la discipline. Une équipe peut vouloir comparer tsc sur une partie TypeScript pure du monorepo, mais il ne faut pas confondre cela avec un support Angular complet.

TypeScript 7 permet aussi de faire cohabiter TypeScript 6 et 7 via des alias npm. L'idée est de laisser certains outils consommer l'API TypeScript 6 pendant que le binaire tsc de TypeScript 7 est disponible pour d'autres usages. C'est intéressant pour des monorepos avancés, mais ce n'est pas une recette magique pour ng build.

Faut-il attendre avant de s'y intéresser ? ​

Non.

Même si Angular ne peut pas encore basculer entièrement, TypeScript 7 donne une indication forte de la direction du tooling JavaScript : plus de compilation native, plus de parallélisation, plus de vitesse dans les éditeurs, et moins de tolérance pour les anciennes configurations héritées des années ES5.

Pour une équipe Angular, le bon réflexe n'est pas de forcer TypeScript 7 aujourd'hui. Le bon réflexe est de préparer le terrain :

  • rester sur les versions officiellement supportées par Angular ;
  • moderniser progressivement tsconfig.json ;
  • supprimer les options dépréciées ;
  • éviter les dépendances à des comportements TypeScript anciens ;
  • surveiller les annonces Angular autour de compiler-cli, du language service et de tsgo.

TypeScript 7 est une excellente nouvelle pour Angular, mais probablement en deux temps. D'abord comme pression positive sur tout l'écosystème TypeScript. Ensuite, quand Angular aura terminé son adaptation, comme gain concret sur les builds, le typage des templates et l'expérience éditeur.

Sources ​