TypeScript 7.0 beta arrive avec une promesse simple et tentante : le compilateur et le language service passent en Go, donc ça va (beaucoup) plus vite. Sur le papier, j’achète tout de suite. En vrai, ton projet ne « tourne » pas sur une slide de keynote. Il tourne sur une chaîne d’outils qui a ses habitudes : tsc, l’IDE, ESLint, les bundlers, les runners, la CI, le monorepo… et c’est là que les surprises arrivent.
L’objectif ici, c’est une adoption sans regret. Comprendre ce que tu installes vraiment avec TS 7 beta, tester en side-by-side sans remplacer TS 6 dans tout le repo, repérer les zones où ça casse, et garder une marche arrière propre. Le gain de perf est cool. Un build rouge « au hasard » la veille d’un release l’est beaucoup moins.
TypeScript 7 beta (tsgo) : ce que tu installes vraiment, et pourquoi ça change tout
Le point important de cette beta, ce n’est pas « TypeScript 7 » au sens du package typescript que tu as l’habitude d’installer. Dans cette beta, Microsoft fournit un outil natif (le fameux tsgo) via un package dédié, @typescript/native-preview. Ça implique deux conséquences très concrètes.
La première, c’est que beaucoup de choses autour de TypeScript ont été écrites en partant du principe qu’il y a un binaire Node qui s’appelle tsc, avec une certaine forme d’API, de sorties, de timings, parfois même des détails de formatting. Quand tu remplaces le moteur, tu touches à la surface de compat. Même si l’équipe TypeScript fait le maximum pour garder la même interface, ce n’est plus le même exécutable, plus la même implémentation, plus les mêmes coins bizarres.
La deuxième, c’est que tu n’es pas obligé de « migrer » ton projet pour tester. Et c’est exactement comme ça qu’il faut le faire. Tu peux garder TypeScript 6 pour le quotidien, et brancher TS 7 beta seulement dans un job CI, ou sur une branche d’expé, histoire de mesurer, de voir les erreurs, et de comprendre ce qui casse.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Le mode side-by-side : tester TS 7 sans remplacer TS 6 dans ton repo
Le piège classique, c’est de faire un npm install, de remplacer typescript par la beta et de prier. Ça marche parfois sur des petits projets. Sur une codebase vivante, ça te met surtout dans une situation où tu ne sais plus si le problème vient du code, du tooling, ou de la beta. Side-by-side, tu gardes un référentiel stable (TS 6), et tu ajoutes un deuxième chemin (TS 7) pour comparer.
Concrètement, l’équipe TypeScript propose une approche où tu continues d’avoir TypeScript 6 installé et appelable explicitement, tout en ajoutant le binaire natif de préversion. L’idée est simple : tes scripts « normaux » restent inchangés, et tu ajoutes un script typecheck:ts7 qui tourne en parallèle.
{
"devDependencies": {
"@typescript/native-preview": "beta",
"@typescript/typescript6": "^6",
"typescript": "^6"
},
"scripts": {
"typecheck": "tsc -p tsconfig.json",
"typecheck:ts6": "tsc6 -p tsconfig.json",
"typecheck:ts7": "tsgo -p tsconfig.json"
}
}
Je te conseille de garder typecheck sur TS 6 au début, et de faire vivre TS 7 dans un job CI séparé. Comme ça, tu récoltes les warnings et les erreurs de compat sans bloquer les merges. Et surtout, tu peux mesurer.
Brancher TS 7 en CI sans mettre le feu : un job dédié, pas un « big bang »
En CI, le meilleur compromis que j’ai trouvé sur ce genre de préversion, c’est un job « non bloquant » au début. Tu le lances sur les PR, tu publies le résultat, tu regardes les deltas. Une fois que tu as compris les écarts, tu peux décider de le rendre bloquant sur certaines branches, ou de le garder en signal faible jusqu’à la stable.
Un exemple GitHub Actions typique, c’est un job qui installe le repo normalement (avec lockfile), puis lance npm run typecheck:ts7. Le fait de rester dans ton pipeline normal te permet aussi de voir les interactions avec cache, monorepo, Node version, etc.
name: CI
on:
pull_request:
jobs:
typecheck_ts7:
runs-on: ubuntu-latest
continue-on-error: true
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
- run: npm ci
- run: npm run typecheck:ts7
Le continue-on-error est volontaire au début. Ça évite « l’effet panique ». Tu veux des infos, pas une révolte. Et si tu es en monorepo, tu peux même cibler un package à la fois, pour éviter de te retrouver avec 800 erreurs indistinctes.
Les points de casse probables : là où ton tooling va te surprendre
La perf, c’est sexy. Mais la réalité du quotidien, c’est l’ergonomie de ton IDE et la fiabilité de tes outils autour. TS 7 beta touche au compilateur et au language service. Donc mécaniquement, les intégrations qui parlent au language service (ou qui s’attendent à certains comportements) sont les premières candidates aux surprises.
Côté éditeur, le premier sujet c’est l’intégration TypeScript elle-même. VS Code embarque son propre TypeScript pour plein de fonctionnalités. Si tu testes tsgo dans ton repo mais que ton IDE continue de tourner sur une version différente, tu peux avoir des diagnostics qui ne matchent pas, ou une sensation de « c’est vert dans l’éditeur mais rouge en CI ». Ce n’est pas forcément un bug. C’est juste deux moteurs différents. Le test side-by-side aide justement à garder ça sous contrôle.
Côté linting, ESLint ne « comprend » pas TypeScript par magie. Il s’appuie sur un parser, des settings, et parfois une lecture de tsconfig (type-aware lint). Si ton pipeline ESLint dépend d’une version précise du parser ou d’un comportement du compilateur, tu peux tomber sur des erreurs plus bruyantes que prévu. Mon conseil : ne mélange pas tout. Commence par typecheck pur avec TS 7, et seulement ensuite regarde ce que ça donne sur les jobs ESLint qui font du type-aware.
Côté bundlers et tooling de build (Vite, tsup, SWC, esbuild, Babel…), rappelle-toi un truc : beaucoup de projets ne compilent pas avec tsc en prod. Ils utilisent TypeScript pour checker et pour générer des types, mais la transpilation est faite ailleurs. Donc TS 7 te donnera un bénéfice énorme sur la partie « vérification / language service / d.ts », mais pas forcément sur la partie « bundling ». Et ça, si tu ne le mesures pas, tu vas te raconter une histoire.
Les « nouveaux defaults » : le genre de détail qui te fait croire que TS 7 est cassé
Dans l’annonce, il y a un point qui mérite d’être lu avec attention : TypeScript 7 beta s’accompagne de changements de comportements par défaut dans certains scénarios (notamment autour des options que tu obtiens quand tu initialises une config, ou quand ton projet s’appuie implicitement sur des valeurs par défaut). Typiquement, si tu as des repos où le tsconfig est incomplet, ou des packages qui reposent sur « ce que TypeScript choisit tout seul », tu peux voir apparaître des différences de diagnostics.
Je le dis franchement : si ton projet n’a pas une base de tsconfig claire, ce n’est pas TS 7 le problème. C’est une dette qui était juste invisible. Et la beta peut te la rendre très visible d’un coup.
Le réflexe utile, c’est de figer ce que tu veux vraiment. Choisis explicitement ton module, ton target, ton niveau de strict, tes résolutions ESM si tu es en NodeNext/Bundler, et arrête de laisser « le compilateur deviner ». Tu gagneras en stabilité, TS 7 ou pas.
Monorepo : project references, incremental, paths, ESM… le vrai crash test
Si tu as un monorepo avec project references, builds incrémentaux, et des paths partout, c’est là que TS 7 devient intéressant… et dangereux. Intéressant parce que le typecheck et les rebuilds peuvent coûter très cher sur de grosses bases. Dangereux parce que tu es exactement dans les zones où le moindre changement de comportement ou de perf peut révéler des hypothèses cachées.
Le premier endroit où je regarde, c’est la génération des .d.ts. Beaucoup de repos ont des scripts qui packagent, publient, ou valident des types. Si TS 7 produit des sorties légèrement différentes, ou si tes tests snapshot sur des declarations sont trop stricts, tu vas te battre contre des différences qui n’ont aucun impact utilisateur mais qui cassent ton pipeline. Là, la bonne question n’est pas « comment forcer TS 7 à faire exactement pareil », c’est plutôt « est-ce que mon pipeline est raisonnable ». Un diff de .d.ts n’est pas toujours un bug. Parfois c’est juste un tooling trop fragile.
Le deuxième endroit, c’est ESM. Entre moduleResolution, exports, les extensions, les imports type-only, les dual packages, il suffit d’un petit changement d’interprétation pour te créer un festival d’erreurs « cannot find module ». Si ton repo est en transition CJS → ESM, teste TS 7 sur un périmètre réduit d’abord. Sinon tu ne sauras jamais si tu es en train de débugger TS 7 ou ta migration ESM.
Enfin, l’incrémental. Sur un gros monorepo, l’intérêt de TypeScript c’est souvent « je veux un typecheck qui ne me détruit pas la journée ». TS 7 promet de gros gains, donc tu as envie d’y croire. Mais le test utile, ce n’est pas un run à froid. C’est la série : run à froid, puis run avec cache, puis run après un petit changement dans un package feuille, puis run après un changement dans une lib centrale. C’est là que tu verras si tu gagnes vraiment du temps sur le cycle qui compte.
Perf : quand tsgo change la donne, et quand tu ne verras… presque rien
Sur un gros repo, une CI lente, ou des devs qui passent leur vie à attendre que « TypeScript finisse », TS 7 peut être un vrai game changer. Le typecheck et le language service sont des coûts récurrents. Si tu divises ça, tu récupères du temps humain, pas juste des secondes sur un benchmark.
À l’inverse, si ton repo est petit, si tu ne fais pas de build incrémental, si le typecheck est déjà rapide, ou si ton pipeline est surtout limité par les tests e2e, le bundling, ou le téléchargement de dépendances, tu ne vas pas sentir grand-chose. Et c’est OK. Tout n’a pas besoin d’être « sur la dernière beta ».
Mon avis : le bon déclencheur pour tester TS 7, ce n’est pas « la hype ». C’est un symptôme. Une CI qui typecheck en 6-10 minutes. Un IDE qui rame sur un workspace. Des devs qui coupent le type-aware lint parce que « c’est trop lent ». Là, oui, ça vaut le coup d’investir une demi-journée propre pour mesurer TS 7.
Stratégie de rollback : le seul truc qui te permet d’oser tester
Tester une beta, ça se fait bien quand tu peux revenir en arrière sans douleur. Et la réalité, c’est que les rollbacks foireux viennent rarement du code. Ils viennent de la gestion des versions.
Le minimum syndical, c’est de pinner précisément les versions (pas « beta flottant » partout), de s’appuyer sur le lockfile, et de garder TS 7 dans des scripts séparés. Si tu fais ça, ton rollback c’est un revert de commit, pas une chasse au trésor.
Et si tu veux être encore plus serein, mets TS 7 derrière un « feature flag CI » très bête : une variable qui active ou non le job. Comme ça, même si TS 7 se met à produire un faux positif sur une PR critique, tu ne bloques pas ton équipe. Tu coupes le job, tu respires, tu reviens dessus après.
Mon avis terrain : teste tôt, mais ne « migre » pas tant que ton IDE n’est pas aligné
Je suis plutôt pro « tester tôt ». Pas pour jouer, mais pour ne pas découvrir les problèmes trois jours avant une stable. Par contre, la migration réelle, celle qui impacte tout le monde tous les jours, je la déclenche quand l’écosystème est prêt. Et dans « écosystème », je mets l’éditeur, les plugins, les parsers ESLint, et les outils de build qui tournent dans ta boîte.
Le meilleur scénario, c’est celui où TS 7 arrive et tu as juste un typecheck plus rapide. Le pire, c’est celui où tu gagnes 40% en CI mais tu perds la confiance dans les diagnostics parce que l’IDE et la CI ne racontent plus la même histoire. Donc oui, mesure tsgo dès maintenant si tu as un gros repo. Mais garde TS 6 comme référence, et laisse le temps aux intégrations de se stabiliser.
