Next.js 15.5 bloque TypeScript 7 : un message d’erreur vaut mieux qu’un faux support

La version Next.js 15.5.22, publiée le 25 juillet, ne contient qu’un changement : elle refuse désormais de démarrer avec TypeScript 7 et affiche une erreur compréhensible. Ce n’est pas encore du support. C’est une barrière posée devant une combinaison de versions qui cassait de manière beaucoup moins claire.

Le correctif paraît minuscule, mais il illustre bien une règle des mises à jour de dépendances : un outil peut conserver la même commande et le même nom de paquet tout en changeant suffisamment d’architecture pour casser les intégrations autour de lui.

## Pourquoi Next.js refuse TypeScript 7

Jusqu’à TypeScript 6, des outils comme Next.js pouvaient charger le compilateur depuis Node.js avec quelque chose qui ressemblait à ceci :

const ts = require("typescript")

Cette API permettait notamment de lire la configuration, lancer la vérification des types et récupérer les diagnostics sans créer un second processus. Or TypeScript 7 a été porté en Go et distribue désormais un exécutable natif. La version 7.0 ne fournit pas encore l’ancienne API JavaScript chargée par require("typescript"). Une nouvelle API est prévue pour TypeScript 7.1.

Pour Next.js 15.5, l’installation de TypeScript 7 pouvait donc ressembler à une dépendance absente. Le framework cherchait un fichier qui n’existait plus, puis échouait avec un comportement peu exploitable. Le correctif intégré dans la branche 15.5 lit maintenant la version depuis le package.json avant de charger le compilateur. Toute version supérieure ou égale à 7.0, y compris les bêta, RC et nightly, est arrêtée proprement dans next dev comme dans next build.

Autrement dit, Next.js 15.5.22 ne rend pas TypeScript 7 incompatible : il rend une incompatibilité existante visible.

## Le compilateur fonctionne, mais pas forcément son écosystème

La confusion est facile. TypeScript 7 conserve la commande tsc, s’installe toujours depuis le paquet `typescript` et vise une compatibilité de vérification avec TypeScript 6. Un npx tsc --noEmit peut donc fonctionner alors que next build échoue.

La rupture se situe entre deux usages différents :

exécuter le compilateur comme un programme avec sa CLI ;
importer le compilateur comme une bibliothèque depuis un autre outil.

Le premier est disponible dans TypeScript 7. Le second attendra la nouvelle API. Cette distinction concerne aussi les outils qui embarquent profondément TypeScript, notamment typescript-eslint, ainsi que certains environnements pour langages intégrés. L’équipe TypeScript recommande temporairement une installation côte à côte avec `@typescript/typescript6` lorsque l’ancienne API reste nécessaire.

Ce compromis existe parce que le gain du nouveau compilateur est réel. Sur les mesures publiées par Microsoft, les compilations complètes de projets comme Visual Studio Code ou Playwright sont environ 8 à 12 fois plus rapides avec TypeScript 7. Mais ces performances ne suffisent pas à rendre automatiquement compatibles les frameworks qui dépendaient de ses composants internes.

## Que faire sur un projet Next.js 15.5

Le choix raisonnable reste de conserver une version 6 de TypeScript explicitement verrouillée :

bash

npm install --save-dev typescript@6.0.2

Il faut ensuite vérifier la version réellement résolue et exécuter le build complet :

bash

npm ls typescript
npm run build

Quelques précautions simples évitent la mise à jour surprise :

ne pas fusionner automatiquement une montée majeure de TypeScript proposée par un bot ;
tester next build, pas seulement tsc --noEmit ;
conserver le fichier de verrouillage dans Git ;
reproduire en CI la même commande que celle utilisée pour construire l’image ou le service déployé sur le VPS ;
traiter séparément la migration de Next.js et celle de TypeScript.

Le support de TypeScript 7 passe par un backend utilisant directement la CLI. Un backport expérimental a été intégré à la branche Next.js 16.2, avec l’option experimental.useTypeScriptCli. Cela montre la direction prise, mais le mot important reste expérimental. Pour un projet personnel en production, gagner quelques secondes de vérification ne justifie pas forcément d’ajouter deux migrations simultanées.

## Le vrai signal envoyé par ce patch

Une erreur explicite constitue ici une amélioration, même si elle bloque une version plus récente. Elle transforme un crash ambigu en décision technique claire : rester sur TypeScript 6, ou migrer vers une version de Next.js dont le chemin TypeScript 7 a été volontairement activé et testé.

Les numéros de version ne suffisent plus pour juger la compatibilité. Avec un compilateur passé de JavaScript à Go, il faut regarder non seulement le langage accepté, mais aussi la manière dont les outils appellent le compilateur. C’est moins visible dans un package.json, mais c’est précisément là que la migration se joue.

## Pour aller plus loin

Veille rédigée avec l'aide d'une IA — sources vérifiées et liées ci-dessus.