TypeScript 7 avec Next.js, ESLint et MDX : ce qui fonctionne réellement

TypeScript 7 est officiellement stable depuis le 8 juillet 2026, mais cette stabilité ne rend pas automatiquement compatibles Next.js, ESLint et les outils MDX. Le nouveau compilateur natif sait vérifier un projet TypeScript et TSX beaucoup plus rapidement, tandis qu’une partie de l’écosystème continue de charger l’ancienne API JavaScript du compilateur, qui n’existe plus dans le package TypeScript 7.

Cette différence explique les retours apparemment contradictoires apparus depuis la sortie. Une commande tsc --noEmit peut réussir, le serveur de développement peut afficher les pages et le build peut pourtant échouer au moment où Next.js ou ESLint tente d’importer typescript. Un projet qui produit du JavaScript n’est pas nécessairement un projet dont toute la chaîne TypeScript 7 fonctionne.

L’article consacré au choix entre migrer maintenant vers TypeScript 7 ou attendre TypeScript 7.1 pose la décision générale. Ici, l’objectif est plus précis : séparer ce qui fonctionne déjà dans une application Next.js de ce qui reste expérimental, incompatible ou dépendant de TypeScript 6.

Pourquoi la compatibilité de l’écosystème compte plus que le compilateur seul

Une application Next.js moderne ne confie pas toutes les étapes au même outil. Turbopack ou SWC transforme les fichiers TypeScript en JavaScript, Next.js orchestre le build et génère certains types, ESLint analyse le code avec son propre parseur, tandis que MDX passe par une chaîne unified, remark et rehype avant de devenir du JSX. TypeScript intervient à plusieurs endroits, mais pas toujours de la même manière.

Le nouveau package TypeScript 7 contient le compilateur natif et son exécutable tsc, mais plus le fichier lib/typescript.js qui exposait historiquement l’API du compilateur. Une commande externe capable de lancer tsc peut donc fonctionner. Un outil qui fait import ts from 'typescript' pour créer un programme, lire le graphe des types ou enrichir son langage doit attendre la nouvelle API annoncée pour TypeScript 7.1, ou continuer à charger TypeScript 6.

C’est cette frontière qui doit guider l’audit. La question « est-ce que Next.js supporte TypeScript 7 ? » est trop large : il faut préciser si l’on parle de la transpilation, de la vérification pendant next build, du plugin TypeScript de l’éditeur, du lint, du chargement de next.config.ts ou de l’analyse des fichiers MDX.

TypeScript 7 et Next.js

Au 12 juillet 2026, la version stable la plus récente de Next.js est la 16.2.10. Elle s’appuie encore par défaut sur l’API JavaScript de TypeScript pour vérifier l’installation, lire la configuration et lancer son contrôle de types intégré. Avec typescript@7.0.2 installé sous son nom normal, cette détection peut considérer que TypeScript manque, alors même que npx tsc --version répond correctement.

Vercel a réagi rapidement. La pull request officielle ajoutant un backend TypeScript fondé sur la CLI a été fusionnée le 10 juillet, puis publiée dans Next.js 16.3.0-canary.83. Le drapeau expérimental useTypeScriptCli permet à next build d’exécuter le compilateur local au lieu de charger son ancienne API.

Compilation et vérification des types

La compilation des fichiers .ts et .tsx n’est pas le principal obstacle. Next.js utilise son bundler pour transformer le code destiné au navigateur ou au serveur, et cette étape peut réussir avec une base de code compatible. Le contrôle des types est séparé : la documentation Next.js rappelle que next build lance une vérification et échoue lorsqu’il rencontre une erreur, sauf désactivation explicite.

Dans la version stable, cette vérification intégrée passe encore par le backend historique. Installer TypeScript 7 directement peut donc provoquer une erreur de dépendance avant même l’analyse du projet. Désactiver ignoreBuildErrors ne résout pas le problème de compatibilité ; l’activer n’est pas non plus une migration, puisqu’il supprime simplement la barrière de contrôle au lieu de faire fonctionner TypeScript 7.

Le backend canary change le mécanisme. Next.js récupère la configuration effective avec tsc --showConfig, lance la CLI locale et restitue ses diagnostics dans le build. Les tests ajoutés par Vercel couvrent Turbopack, Webpack, TypeScript 6 et TypeScript 7. C’est une avancée concrète, mais le drapeau reste explicitement expérimental et n’appartient pas encore à une version stable.

Développement local et production

En développement, Turbopack peut servir une application qui contient du TypeScript 7, car il n’a pas besoin de l’API complète pour retirer les types et produire les modules. L’éditeur peut également utiliser le nouveau serveur de langage TypeScript 7 pour les fichiers TypeScript et TSX. Ces deux réussites ne garantissent toutefois pas le maintien des fonctions propres au plugin TypeScript de Next.js ni la parité avec le contrôle exécuté en production.

La modification intégrée par Vercel cible surtout la vérification pendant next build. Elle ne remplace pas encore chaque interaction entre Next.js et l’API TypeScript : types générés, plugins de langage et configurations particulières doivent être testés séparément.

Passer de Next.js stable à une canary uniquement pour adopter TypeScript 7 cumule deux migrations. La démarche est pertinente sur une branche technique ou un dépôt de test, rarement comme mise à jour urgente d’une application déjà exploitée.

Points à tester sur un projet existant

Le test doit couvrir davantage que npx tsc --noEmit : démarrage local, routes réellement utilisées, génération statique, Server Components, next.config.ts, types de routes et build avec le bundler de production.

Les lockfiles et workspaces méritent une attention particulière. Un package résiduel peut encore fournir l’API TypeScript 6 en local, puis disparaître dans un runner vierge. La cohérence doit être vérifiée après une réinstallation stricte des dépendances.

Cette précaution rejoint le travail décrit dans la maintenance d’une application web ou d’un SaaS : une mise à jour structurante se valide sur un environnement reproductible, avec ses commandes de développement, de contrôle et de production, pas uniquement sur le poste qui a servi à modifier le package.

TypeScript 7 et typescript-eslint

La situation de typescript-eslint est plus tranchée. Sa documentation des versions prises en charge indique encore une plage TypeScript allant de >=4.8.4 à <6.1.0. TypeScript 7 n’est donc pas officiellement accepté au 12 juillet 2026.

Ce blocage ne correspond pas à une simple contrainte de peerDependencies oubliée. Le parseur @typescript-eslint/typescript-estree utilise l’API TypeScript pour lire le code, produire un AST compatible avec ESLint et, lorsque la configuration le demande, associer les nœuds syntaxiques aux informations du vérificateur de types.

Pourquoi l’intégration est sensible

ESLint ne comprend pas nativement toute la syntaxe et la sémantique TypeScript. typescript-eslint construit la passerelle entre les deux mondes : il importe TypeScript, analyse ses structures et expose les données nécessaires aux règles. Les règles typées comme no-floating-promises ou no-misused-promises ont besoin du programme TypeScript, mais même le chargement du parseur peut accéder à des constantes et fonctions absentes du package 7.0.

Forcer l’installation malgré la plage de versions ne produit donc pas seulement un avertissement théorique. Des reproductions récentes montrent des échecs de npm ci sur le conflit de dépendances, puis des plantages au lancement d’ESLint lorsque l’installation est imposée. Le ticket de suivi consacré à l’utilisation de TypeScript 7 pour les informations de types reste ouvert et décrit un travail d’architecture plus large qu’une simple mise à jour de numéro.

Retirer temporairement toutes les règles typées ne suffit pas nécessairement, puisque le parseur lui-même dépend encore de l’API JavaScript. Remplacer typescript-eslint par le parseur JavaScript standard ferait perdre la compréhension de la syntaxe TypeScript et ne constitue pas une solution réaliste pour un projet sérieux.

Ce qui peut bloquer une migration

Le premier blocage apparaît souvent à l’installation : npm refuse un graphe où typescript-eslint demande TypeScript 6 tandis que le projet expose TypeScript 7 sous le package typescript. Avec un gestionnaire plus permissif ou une option de contournement, l’installation peut réussir mais déplacer l’erreur vers le lint, l’éditeur ou la CI.

La stratégie officielle consiste à faire cohabiter les deux générations. Le nom typescript reste associé au package de compatibilité TypeScript 6, afin que Next.js stable et typescript-eslint retrouvent l’API attendue. TypeScript 7 est installé sous un alias distinct et son binaire est lancé explicitement pour comparer les diagnostics et les performances.

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.2",
    "@typescript/native": "npm:typescript@^7.0.2"
  }
}

Cette configuration évite de désactiver ESLint et conserve un chemin de retour simple. Elle impose toutefois de nommer clairement les scripts, de verrouiller le gestionnaire de paquets et de vérifier quel exécutable est réellement appelé. Une coexistence mal documentée peut donner l’impression que toute la chaîne utilise TypeScript 7 alors que seuls certains contrôles passent par le compilateur natif.

TypeScript 7 dans un projet MDX

MDX ajoute une autre ambiguïté, car le mot « compatibilité » recouvre au moins trois opérations : transformer le contenu en JavaScript, typer les composants importés et fournir des diagnostics à l’intérieur du fichier .mdx. Ces opérations ne reposent pas toutes sur TypeScript de la même manière.

Le package officiel @mdx-js/mdx compile MDX en JavaScript à travers l’écosystème unified. Il expose lui-même des définitions TypeScript, mais son travail principal consiste à parser le Markdown, le JSX et les plugins remark ou rehype. Une page MDX peut donc être transformée et rendue sans que le compilateur TypeScript 7 analyse directement chaque paragraphe.

Contenus éditoriaux et composants React

Dans Next.js, le plugin @next/mdx prend en charge les contenus locaux et leur utilisation avec les Server Components. La documentation MDX de Next.js impose notamment un fichier mdx-components.tsx avec l’App Router. Ce fichier est un composant TypeScript classique : ses props, imports et composants peuvent être vérifiés comme le reste de l’application.

Les imports effectués depuis un fichier MDX et les composants qu’il appelle ajoutent cependant une couche. Les déclarations fournies par @types/mdx, les types React et l’espace de noms JSX doivent rester cohérents. Un build réussi prouve que la chaîne de transformation connaît le format, mais pas que l’éditeur est capable de fournir les mêmes diagnostics TypeScript 7 au sein du document MDX.

Microsoft cite explicitement MDX parmi les workflows qui ne peuvent pas encore exploiter pleinement TypeScript 7. La raison est la même que pour les autres langages embarqués : les analyseurs et services de langage transforment souvent le contenu en fichier virtuel, puis appellent l’API TypeScript pour calculer les types et relier les diagnostics au document d’origine.

Analyse des types et tooling associé

Un projet éditorial peut donc fonctionner avec une chaîne hybride. Next.js compile les pages MDX, TypeScript 6 alimente les outils qui ont besoin de l’API historique, tandis que TypeScript 7 vérifie séparément les fichiers .ts et .tsx. Cette séparation offre déjà un terrain de mesure, mais elle ne constitue pas une migration MDX complète.

Les plugins remark et rehype ne sont pas automatiquement incompatibles : beaucoup manipulent des arbres Markdown ou HTML sans charger TypeScript. Un plugin personnalisé qui analyse du code, génère des types ou extrait des exports doit en revanche être audité séparément.

Dans l’éditeur, il faut tester un composant TSX, un MDX simple et un MDX important des composants typés. La coloration syntaxique ne garantit ni les erreurs de props, ni les renommages, ni la navigation vers les définitions.

La matrice de test minimale avant adoption

Une migration crédible doit produire des résultats séparés pour chaque couche. Le tableau suivant ne cherche pas à couvrir tous les frameworks et plugins possibles, mais à empêcher qu’un succès local masque un échec dans la chaîne réelle.

Le test doit également inventorier les outils moins visibles : générateur de documentation, tests qui chargent TypeScript, scripts AST, ts-morph, plugins de traduction, extraction de contenu, Storybook ou outils de génération d’API. La dépendance à TypeScript peut être transitive et n’apparaître qu’après la mise à jour.

Sur une application web ou un SaaS sur mesure, le niveau de preuve attendu dépend de la criticité. Un site éditorial tolère plus facilement une expérience d’éditeur temporairement dégradée qu’un produit où le lint typé protège des flux de paiement, de droits ou de données sensibles. La décision technique doit rester proportionnée au risque métier.

Migrer, faire cohabiter ou attendre ?

Pour une application Next.js stable qui utilise typescript-eslint et MDX, la migration complète vers TypeScript 7 n’est pas encore le choix le plus robuste au 12 juillet 2026. Le compilateur est prêt, mais deux éléments centraux de la chaîne dépendent toujours de l’API TypeScript 6, tandis que le support natif de Next.js vient seulement d’apparaître derrière un drapeau canary.

La cohabitation est actuellement l’option la plus intéressante pour un projet assez volumineux pour bénéficier des gains de TypeScript 7. Elle permet de lancer le nouveau tsc dans une commande dédiée ou une étape de CI expérimentale, tout en conservant TypeScript 6 pour Next.js stable, ESLint et l’analyse MDX. Les écarts peuvent ainsi être observés sans réduire les contrôles existants.

Utiliser Next.js 16.3.0-canary.83 avec experimental.useTypeScriptCli a du sens pour valider la direction prise par Vercel et préparer une future migration. Cela reste une expérimentation : elle doit vivre sur une branche, un environnement de préproduction ou un dépôt représentatif, pas remplacer automatiquement une version stable parce que le compilateur est plus rapide.

Attendre ne signifie enfin pas rester immobile. Le projet peut être mis à niveau vers TypeScript 6, débarrassé de ses options dépréciées, testé avec une installation parallèle et documenté par couche. Lorsque Next.js stabilisera son backend CLI et que typescript-eslint disposera d’une stratégie pour la nouvelle API, la migration finale deviendra une évolution maîtrisée plutôt qu’une enquête menée après un build cassé.