BackRetour au blog

Next.js 15

Next.js 15 introduit le support de React 19, des améliorations de mise en cache, une version stable de Turbopack en développement, de nouvelles APIs et plus encore.

Next.js 15 est officiellement stable et prêt pour la production. Cette version s'appuie sur les mises à jour des RC1 et RC2. Nous nous sommes concentrés sur la stabilité tout en ajoutant des fonctionnalités excitantes que nous pensons que vous allez adorer. Essayez Next.js 15 dès aujourd'hui :

terminal
# Utilisez le nouveau CLI de mise à niveau automatisé
npx @next/codemod@canary upgrade latest
 
# ...ou mettez à niveau manuellement
npm install next@latest react@rc react-dom@rc

Nous sommes également ravis de partager plus d'informations sur ce qui arrive ensuite lors de la Next.js Conf ce jeudi 24 octobre.

Voici ce qui est nouveau dans Next.js 15 :

Mises à niveau fluides avec le CLI @next/codemod

Nous incluons des codemods (transformations de code automatisées) avec chaque version majeure de Next.js pour aider à automatiser les mises à niveau des changements cassants.

Pour rendre les mises à niveau encore plus fluides, nous avons publié un CLI de codemod amélioré :

Terminal
npx @next/codemod@canary upgrade latest

Cet outil vous aide à mettre à niveau votre codebase vers les dernières versions stables ou préliminaires. Le CLI mettra à jour vos dépendances, montrera les codemods disponibles et vous guidera pour les appliquer.

Le tag canary utilise la dernière version du codemod tandis que latest spécifie la version de Next.js. Nous recommandons d'utiliser la version canary du codemod même si vous mettez à niveau vers la dernière version de Next.js, car nous prévoyons de continuer à ajouter des améliorations à l'outil en fonction de vos retours.

Apprenez-en plus sur le CLI de codemod Next.js.

APIs de requête asynchrones (Changement cassant)

Dans le rendu côté serveur traditionnel, le serveur attend une requête avant de rendre tout contenu. Cependant, tous les composants ne dépendent pas de données spécifiques à une requête, il est donc inutile d'attendre la requête pour les rendre. Idéalement, le serveur préparerait autant que possible avant l'arrivée d'une requête. Pour permettre cela et préparer le terrain pour des optimisations futures, nous devons savoir quand attendre la requête.

Par conséquent, nous transitionnons les APIs qui dépendent de données spécifiques à une requête — comme headers, cookies, params et searchParams — pour qu'elles soient asynchrones.

import { cookies } from 'next/headers';
 
export async function AdminPanel() {
  const cookieStore = await cookies();
  const token = cookieStore.get('token');
 
  // ...
}

Ceci est un changement cassant et affecte les APIs suivantes :

  • cookies
  • headers
  • draftMode
  • params dans layout.js, page.js, route.js, default.js, generateMetadata et generateViewport
  • searchParams dans page.js

Pour une migration plus facile, ces APIs peuvent temporairement être accédées de manière synchrone, mais afficheront des avertissements en développement et en production jusqu'à la prochaine version majeure. Un codemod est disponible pour automatiser la migration :

Terminal
npx @next/codemod@canary next-async-request-api .

Pour les cas où le codemod ne peut pas migrer entièrement votre code, veuillez lire le guide de mise à niveau. Nous avons également fourni un exemple de comment migrer une application Next.js vers les nouvelles APIs.

Sémantique de cache

Next.js App Router a été lancé avec des valeurs par défaut de cache opinionnées. Celles-ci étaient conçues pour fournir l'option la plus performante par défaut avec la possibilité de se désengager lorsque nécessaire.

Sur la base de vos retours, nous avons réévalué nos heuristiques de cache et comment elles interagiraient avec des projets comme le Partial Prerendering (PPR) et avec des bibliothèques tierces utilisant fetch.

Avec Next.js 15, nous changeons la valeur par défaut du cache pour les gestionnaires de route GET et le Client Router Cache de mis en cache par défaut à non mis en cache par défaut. Si vous souhaitez conserver le comportement précédent, vous pouvez continuer à opter pour la mise en cache.

Nous continuons à améliorer la mise en cache dans Next.js dans les mois à venir et nous partagerons plus de détails bientôt.

Les gestionnaires de route GET ne sont plus mis en cache par défaut

Dans Next 14, les gestionnaires de route utilisant la méthode HTTP GET étaient mis en cache par défaut sauf s'ils utilisaient une fonction dynamique ou une option de configuration dynamique. Dans Next.js 15, les fonctions GET ne sont pas mises en cache par défaut.

Vous pouvez toujours opter pour la mise en cache en utilisant une option de configuration de route statique telle que export dynamic = 'force-static'.

Les gestionnaires de route spéciaux comme sitemap.ts, opengraph-image.tsx et icon.tsx, ainsi que d'autres fichiers de métadonnées restent statiques par défaut sauf s'ils utilisent des fonctions dynamiques ou des options de configuration dynamiques.

Le Client Router Cache ne met plus en cache les composants Page par défaut

Dans Next.js 14.2.0, nous avons introduit un flag expérimental staleTimes pour permettre une configuration personnalisée du Router Cache.

Dans Next.js 15, ce flag reste accessible, mais nous changeons le comportement par défaut pour avoir un staleTime de 0 pour les segments Page. Cela signifie que lorsque vous naviguez dans votre application, le client reflétera toujours les dernières données du composant Page qui devient actif lors de la navigation. Cependant, certains comportements importants restent inchangés :

  • Les données de mise en page partagées ne seront pas rechargées depuis le serveur pour continuer à supporter le rendu partiel.
  • La navigation avant/arrière restaurera toujours depuis le cache pour s'assurer que le navigateur peut restaurer la position de défilement.
  • loading.js restera mis en cache pendant 5 minutes (ou la valeur de la configuration staleTimes.static).

Vous pouvez opter pour le comportement précédent du Client Router Cache en définissant la configuration suivante :

next.config.ts
const nextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 30,
    },
  },
};
 
export default nextConfig;

React 19

Dans le cadre de la sortie de Next.js 15, nous avons pris la décision de nous aligner sur la prochaine version de React 19.

Dans la version 15, l'App Router utilise React 19 RC, et nous avons également introduit une compatibilité descendante pour React 18 avec le Pages Router basée sur les retours de la communauté. Si vous utilisez le Pages Router, cela vous permet de mettre à niveau vers React 19 lorsque vous serez prêt.

Bien que React 19 soit encore en phase RC, nos tests approfondis sur des applications réelles et notre travail étroit avec l'équipe React nous ont donné confiance en sa stabilité. Les changements cassants principaux ont été bien testés et n'affecteront pas les utilisateurs existants de l'App Router. Par conséquent, nous avons décidé de publier Next.js 15 comme stable maintenant, afin que vos projets soient entièrement préparés pour la version GA de React 19.

Pour garantir que la transition soit aussi fluide que possible, nous avons fourni des codemods et outils automatisés pour faciliter le processus de migration.

Lisez le guide de mise à niveau de Next.js 15, le guide de mise à niveau de React 19 et regardez le keynote de React Conf pour en savoir plus.

Pages Router sur React 18

Next.js 15 maintient une compatibilité descendante pour le Pages Router avec React 18, permettant aux utilisateurs de continuer à utiliser React 18 tout en bénéficiant des améliorations de Next.js 15.

Depuis le premier Release Candidate (RC1), nous avons recentré nos efforts pour inclure le support de React 18 basé sur les retours de la communauté. Cette flexibilité vous permet d'adopter Next.js 15 tout en utilisant le Pages Router avec React 18, vous donnant plus de contrôle sur votre chemin de mise à niveau.

Note : Bien qu'il soit possible d'exécuter le Pages Router sur React 18 et l'App Router sur React 19 dans la même application, nous ne recommandons pas cette configuration. Cela pourrait entraîner un comportement imprévisible et des incohérences de typage, car les APIs sous-jacentes et la logique de rendu entre les deux versions peuvent ne pas s'aligner complètement.

Compilateur React (Expérimental)

Le compilateur React est un nouveau compilateur expérimental créé par l'équipe React chez Meta. Le compilateur comprend votre code en profondeur grâce à sa compréhension des sémantiques JavaScript simples et des Règles de React, ce qui lui permet d'ajouter des optimisations automatiques à votre code. Le compilateur réduit la quantité de mémoïsation manuelle que les développeurs doivent faire via des APIs comme useMemo et useCallback - rendant le code plus simple, plus facile à maintenir et moins sujet aux erreurs.

Avec Next.js 15, nous avons ajouté le support pour le compilateur React. Apprenez-en plus sur le compilateur React et les options de configuration disponibles pour Next.js.

Note : Le compilateur React est actuellement uniquement disponible en tant que plugin Babel, ce qui entraînera des temps de développement et de build plus lents.

Améliorations des erreurs d'hydratation

Next.js 14.1 a apporté des améliorations aux messages d'erreur et aux erreurs d'hydratation. Next.js 15 poursuit ces améliorations en ajoutant une vue d'erreur d'hydratation optimisée. Les erreurs d'hydratation affichent désormais le code source de l'erreur avec des suggestions pour résoudre le problème.

Par exemple, voici un message d'erreur d'hydratation dans Next.js 14.1 :

Message d'erreur d'hydratation dans Next.js 14.1

Next.js 15 a amélioré cela comme suit :

Message d'erreur d'hydratation amélioré dans Next.js 15

Turbopack Dev

Nous sommes heureux d'annoncer que next dev --turbo est désormais stable et prêt à accélérer votre expérience de développement. Nous l'avons utilisé pour itérer sur vercel.com, nextjs.org, v0 et toutes nos autres applications avec d'excellents résultats.

Par exemple, avec vercel.com, une grande application Next.js, nous avons observé :

  • Jusqu'à 76,7 % plus rapide au démarrage du serveur local.
  • Jusqu'à 96,3 % plus rapide pour les mises à jour de code avec Fast Refresh.
  • Jusqu'à 45,8 % plus rapide pour la compilation initiale des routes sans cache (Turbopack n'a pas encore de cache disque).

Vous pouvez en savoir plus sur Turbopack Dev dans notre nouvel article de blog.

Indicateur de route statique

Next.js affiche désormais un indicateur de route statique pendant le développement pour vous aider à identifier quelles routes sont statiques ou dynamiques. Ce repère visuel facilite l'optimisation des performances en comprenant comment vos pages sont rendues.

Vous pouvez également utiliser la sortie de next build pour voir la stratégie de rendu de toutes les routes.

Cette mise à jour fait partie de nos efforts continus pour améliorer l'observabilité dans Next.js, facilitant la surveillance, le débogage et l'optimisation des applications par les développeurs. Nous travaillons également sur des outils dédiés aux développeurs, avec plus de détails à venir bientôt.

Apprenez-en plus sur l'Indicateur de route statique, qui peut être désactivé.

Exécution de code après une réponse avec unstable_after (Expérimental)

Lors du traitement d'une requête utilisateur, le serveur effectue généralement des tâches directement liées au calcul de la réponse. Cependant, vous pourriez avoir besoin d'effectuer des tâches telles que la journalisation, l'analyse et d'autres synchronisations avec des systèmes externes.

Comme ces tâches ne sont pas directement liées à la réponse, l'utilisateur ne devrait pas avoir à attendre leur achèvement. Reporter le travail après la réponse à l'utilisateur pose un défi car les fonctions serverless arrêtent le calcul immédiatement après la fermeture de la réponse.

after() est une nouvelle API expérimentale qui résout ce problème en vous permettant de planifier un travail à exécuter après la fin du streaming de la réponse, permettant ainsi aux tâches secondaires de s'exécuter sans bloquer la réponse principale.

Pour l'utiliser, ajoutez experimental.after à next.config.js :

next.config.ts
const nextConfig = {
  experimental: {
    after: true,
  },
};
 
export default nextConfig;

Ensuite, importez la fonction dans les composants serveur, les actions serveur, les gestionnaires de route ou le middleware.

import { unstable_after as after } from 'next/server';
import { log } from '@/app/utils';
 
export default function Layout({ children }) {
  // Tâche secondaire
  after(() => {
    log();
  });
 
  // Tâche principale
  return <>{children}</>;
}

Apprenez-en plus sur unstable_after.

instrumentation.js (Stable)

Le fichier instrumentation, avec l'API register(), permet aux utilisateurs de s'intégrer au cycle de vie du serveur Next.js pour surveiller les performances, suivre la source des erreurs et s'intégrer profondément avec des bibliothèques d'observabilité comme OpenTelemetry.

Cette fonctionnalité est désormais stable et l'option de configuration experimental.instrumentationHook peut être supprimée.

De plus, nous avons collaboré avec Sentry pour concevoir un nouveau hook onRequestError qui peut être utilisé pour :

  • Capturer des informations importantes sur toutes les erreurs survenues sur le serveur, y compris :
    • Routeur : Pages Router ou App Router
    • Contexte serveur : Composant serveur, Action serveur, Gestionnaire de route ou Middleware
  • Signaler les erreurs à votre fournisseur d'observabilité préféré.
export async function onRequestError(err, request, context) {
  await fetch('https://...', {
    method: 'POST',
    body: JSON.stringify({ message: err.message, request, context }),
    headers: { 'Content-Type': 'application/json' },
  });
}
 
export async function register() {
  // initialisez le SDK de votre fournisseur d'observabilité préféré
}

Apprenez-en plus sur la fonction onRequestError.

Composant <Form>

Le nouveau composant <Form> étend l'élément HTML <form> avec le préchargement, la navigation côté client et l'amélioration progressive.

Il est utile pour les formulaires qui naviguent vers une nouvelle page, comme un formulaire de recherche qui mène à une page de résultats.

app/page.jsx
import Form from 'next/form';
 
export default function Page() {
  return (
    <Form action="/search">
      <input name="query" />
      <button type="submit">Submit</button>
    </Form>
  );
}

Le composant <Form> inclut :

  • Préchargement : Lorsque le formulaire est visible, l'interface layout et loading est préchargée, rendant la navigation rapide.
  • Navigation côté client : Lors de la soumission, les layouts partagés et l'état côté client sont préservés.
  • Amélioration progressive : Si JavaScript n'est pas encore chargé, le formulaire fonctionne toujours via une navigation de page complète.

Auparavant, l'implémentation de ces fonctionnalités nécessitait beaucoup de code standard manuel. Par exemple :

Exemple

// Note : Ceci est abrégé à des fins de démonstration.
// Non recommandé pour une utilisation en production.
 
'use client'
 
import { useEffect } from 'react'
import { useRouter } from 'next/navigation'
 
export default function Form(props) {
  const action = props.action
  const router = useRouter()
 
  useEffect(() => {
    // si la cible du formulaire est une URL, préchargez-la
    if (typeof action === 'string') {
      router.prefetch(action)
    }
  }, [action, router])
 
  function onSubmit(event) {
    event.preventDefault()
 
    // récupérez tous les champs du formulaire et déclenchez un `router.push` avec les données encodées dans l'URL
    const formData = new FormData(event.currentTarget)
    const data = new URLSearchParams()
 
    for (const [name, value] of formData) {
      data.append(name, value as string)
    }
 
    router.push(`${action}?${data.toString()}`)
  }
 
  if (typeof action === 'string') {
    return <form onSubmit={onSubmit} {...props} />
  }
 
  return <form {...props} />
}

Apprenez-en plus sur le composant <Form>.

Prise en charge de next.config.ts

Next.js prend désormais en charge le type de fichier TypeScript next.config.ts et fournit un type NextConfig pour l'autocomplétion et les options typées :

next.config.ts
import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  /* options de configuration ici */
};
 
export default nextConfig;

Apprenez-en plus sur la prise en charge de TypeScript dans Next.js.

Améliorations pour l'auto-hébergement

Lors de l'auto-hébergement d'applications, vous pourriez avoir besoin de plus de contrôle sur les directives Cache-Control.

Un cas courant est le contrôle de la période stale-while-revalidate envoyée pour les pages ISR. Nous avons implémenté deux améliorations :

  1. Vous pouvez maintenant configurer la valeur expireTime dans next.config. C'était auparavant l'option experimental.swrDelta.
  2. Mise à jour de la valeur par défaut à un an, garantissant que la plupart des CDN peuvent appliquer pleinement la sémantique stale-while-revalidate comme prévu.

Nous ne remplaçons plus non plus les valeurs personnalisées Cache-Control par nos valeurs par défaut, permettant un contrôle total et garantissant la compatibilité avec toute configuration de CDN.

Enfin, nous avons amélioré l'optimisation des images lors de l'auto-hébergement. Auparavant, nous recommandions d'installer sharp pour optimiser les images sur votre serveur Next.js. Cette recommandation était parfois oubliée. Avec Next.js 15, vous n'avez plus besoin d'installer manuellement sharp — Next.js utilisera automatiquement sharp lors de l'utilisation de next start ou lors de l'exécution en mode de sortie autonome.

Pour en savoir plus, consultez notre nouvelle démonstration et vidéo tutorielle sur l'auto-hébergement de Next.js.

Sécurité renforcée pour les actions serveur

Les actions serveur sont des fonctions côté serveur qui peuvent être appelées depuis le client. Elles sont définies en ajoutant la directive 'use server' en haut d'un fichier et en exportant une fonction asynchrone.

Même si une action serveur ou une fonction utilitaire n'est pas importée ailleurs dans votre code, c'est toujours un point de terminaison HTTP accessible publiquement. Bien que ce comportement soit techniquement correct, il peut conduire à une exposition involontaire de ces fonctions.

Pour améliorer la sécurité, nous avons introduit les améliorations suivantes :

  • Élimination du code mort : Les actions serveur inutilisées n'auront pas leurs IDs exposés dans le bundle JavaScript côté client, réduisant la taille du bundle et améliorant les performances.
  • IDs d'action sécurisés : Next.js crée désormais des IDs non devinables et non déterministes pour permettre au client de référencer et d'appeler l'action serveur. Ces IDs sont recalculés périodiquement entre les builds pour une sécurité renforcée.
// app/actions.js
'use server';
 
// Cette action **est** utilisée dans notre application, donc Next.js
// créera un ID sécurisé pour permettre au client de référencer
// et d'appeler l'action serveur.
export async function updateUserAction(formData) {}
 
// Cette action **n'est pas** utilisée dans notre application, donc Next.js
// supprimera automatiquement ce code lors de `next build`
// et ne créera pas de point de terminaison public.
export async function deleteUserAction(formData) {}

Vous devriez toujours traiter les actions serveur comme des points de terminaison HTTP publics. Apprenez-en plus sur la sécurisation des actions serveur.

Optimisation du bundling des packages externes (Stable)

Le bundling des packages externes peut améliorer les performances de démarrage à froid de votre application. Dans le App Router, les packages externes sont inclus par défaut dans le bundle, et vous pouvez exclure des packages spécifiques en utilisant la nouvelle option de configuration serverExternalPackages.

Dans le Pages Router, les packages externes ne sont pas inclus par défaut dans le bundle, mais vous pouvez fournir une liste de packages à inclure en utilisant l'option existante transpilePackages. Avec cette option de configuration, vous devez spécifier chaque package.

Pour unifier la configuration entre App et Pages Router, nous introduisons une nouvelle option, bundlePagesRouterDependencies pour correspondre à l'inclusion automatique par défaut du App Router. Vous pouvez ensuite utiliser serverExternalPackages pour exclure des packages spécifiques, si nécessaire.

next.config.ts
const nextConfig = {
  // Inclure automatiquement les packages externes dans le Pages Router :
  bundlePagesRouterDependencies: true,
  // Exclure des packages spécifiques du bundling pour les deux App et Pages Router :
  serverExternalPackages: ['nom-du-package'],
};
 
export default nextConfig;

Apprenez-en plus sur l'optimisation des packages externes.

Prise en charge d'ESLint 9

Next.js 15 introduit également la prise en charge d'ESLint 9, suite à la fin de vie d'ESLint 8 le 5 octobre 2024.

Pour assurer une transition en douceur, Next.js reste rétrocompatible, ce qui signifie que vous pouvez continuer à utiliser ESLint 8 ou 9.

Si vous passez à ESLint 9 et que nous détectons que vous n'avez pas encore adopté le nouveau format de configuration, Next.js appliquera automatiquement l'échappatoire ESLINT_USE_FLAT_CONFIG=false pour faciliter la migration.

De plus, les options dépréciées comme —ext et —ignore-path seront supprimées lors de l'exécution de next lint. Veuillez noter qu'ESLint finira par interdire ces configurations plus anciennes dans ESLint 10, nous vous recommandons donc de commencer votre migration bientôt.

Pour plus de détails sur ces changements, consultez le guide de migration.

Dans le cadre de cette mise à jour, nous avons également mis à niveau eslint-plugin-react-hooks vers v5.0.0, qui introduit de nouvelles règles pour l'utilisation des hooks React. Vous pouvez consulter tous les changements dans le changelog pour [email protected].

Améliorations du développement et de la construction

HMR pour les composants serveur

Pendant le développement, les composants serveur sont réexécutés lors de leur sauvegarde. Cela signifie que toutes les requêtes fetch vers vos points de terminaison API ou services tiers sont également appelées.

Pour améliorer les performances de développement local et réduire les coûts potentiels des appels API facturés, nous nous assurons désormais que le Hot Module Replacement (HMR) peut réutiliser les réponses fetch des rendus précédents.

Apprenez-en plus sur le cache HMR des composants serveur.

Génération statique plus rapide pour l'App Router

Nous avons optimisé la génération statique pour améliorer les temps de build, en particulier pour les pages avec des requêtes réseau lentes.

Auparavant, notre processus d'optimisation statique rendait les pages deux fois — une fois pour générer les données pour la navigation côté client et une seconde fois pour rendre le HTML pour la visite initiale de la page. Maintenant, nous réutilisons le premier rendu, éliminant ainsi la seconde passe, ce qui réduit la charge de travail et les temps de build.

De plus, les workers de génération statique partagent désormais le cache fetch entre les pages. Si un appel fetch ne désactive pas la mise en cache, ses résultats sont réutilisés par d'autres pages traitées par le même worker. Cela réduit le nombre de requêtes pour les mêmes données.

Contrôle avancé de la génération statique (Expérimental)

Nous avons ajouté une prise en charge expérimentale pour un meilleur contrôle du processus de génération statique, destinée aux cas d'utilisation avancés qui bénéficieraient d'un contrôle accru.

Nous recommandons de rester sur les paramètres par défaut actuels, sauf si vous avez des besoins spécifiques, car ces options peuvent entraîner une utilisation accrue des ressources et des erreurs potentielles de mémoire insuffisante en raison d'une concurrence accrue.

next.config.ts
const nextConfig = {
  experimental: {
    // nombre de tentatives de régénération de pages échouées avant d'échouer le build
    staticGenerationRetryCount: 1
    // nombre de pages traitées par worker
    staticGenerationMaxConcurrency: 8
    // nombre minimum de pages avant de lancer un nouveau worker d'export
    staticGenerationMinPagesPerWorker: 25
  },
}
 
export default nextConfig;

En savoir plus sur les options de génération statique.

Autres changements

  • [Breaking] next/image : Suppression de squoosh en faveur de sharp comme dépendance optionnelle (PR)
  • [Breaking] next/image : Changement du Content-Disposition par défaut en attachment (PR)
  • [Breaking] next/image : Erreur lorsque src contient des espaces en début ou fin (PR)
  • [Breaking] Middleware : Application de la condition react-server pour limiter les imports d'API React non recommandés (PR)
  • [Breaking] next/font : Suppression du support du package externe @next/font (PR)
  • [Breaking] next/font : Suppression du hachage font-family (PR)
  • [Breaking] Cache : force-dynamic définira désormais no-store par défaut pour le cache fetch (PR)
  • [Breaking] Config : Activation par défaut de swcMinify (PR), missingSuspenseWithCSRBailout (PR), et outputFileTracing (PR) et suppression des options obsolètes
  • [Breaking] Suppression de l'auto-instrumentation pour Speed Insights (il faut désormais utiliser le package dédié @vercel/speed-insights) (PR)
  • [Breaking] Suppression de l'extension .xml pour les routes dynamiques de sitemap et alignement des URLs de sitemap entre développement et production (PR)
  • [Breaking] Nous avons déprécié l'export de export const runtime = "experimental-edge" dans l'App Router. Les utilisateurs doivent maintenant utiliser export const runtime = "edge". Nous avons ajouté un codemod pour effectuer cette migration (PR)
  • [Breaking] L'appel de revalidateTag et revalidatePath pendant le rendu générera désormais une erreur (PR)
  • [Breaking] Les fichiers instrumentation.js et middleware.js utiliseront désormais les packages React vendored (PR)
  • [Breaking] La version minimale requise de Node.js a été mise à jour vers 18.18.0 (PR)
  • [Breaking] next/dynamic : la prop obsolète suspense a été supprimée et lorsque le composant est utilisé dans l'App Router, il n'insérera plus de limite Suspense vide (PR)
  • [Breaking] Lors de la résolution de modules sur l'Edge Runtime, la condition worker ne sera plus appliquée (PR)
  • [Breaking] Interdiction d'utiliser l'option ssr: false avec next/dynamic dans les Server Components (PR)
  • [Amélioration] Metadata : Mise à jour des fallbacks des variables d'environnement pour metadataBase lors de l'hébergement sur Vercel (PR)
  • [Amélioration] Correction du tree-shaking avec des imports mixtes namespace et named depuis optimizePackageImports (PR)
  • [Amélioration] Parallel Routes : Fourniture de routes catch-all non matchées avec tous les paramètres connus (PR)
  • [Amélioration] La config bundlePagesExternals est désormais stable et renommée en bundlePagesRouterDependencies
  • [Amélioration] La config serverComponentsExternalPackages est désormais stable et renommée en serverExternalPackages
  • [Amélioration] create-next-app : Les nouveaux projets ignorent désormais tous les fichiers .env par défaut (PR)
  • [Amélioration] Les options outputFileTracingRoot, outputFileTracingIncludes et outputFileTracingExcludes ont été promues de expérimental à stable (PR)
  • [Amélioration] Évite la fusion des fichiers CSS globaux avec les fichiers CSS module plus profonds dans l'arborescence (PR)
  • [Amélioration] Le gestionnaire de cache peut être spécifié via la variable d'environnement NEXT_CACHE_HANDLER_PATH (PR)
  • [Amélioration] Le Pages Router supporte désormais React 18 et React 19 (PR)
  • [Amélioration] L'Error Overlay affiche désormais un bouton pour copier l'URL de l'inspecteur Node.js si celui-ci est activé (PR)
  • [Amélioration] Les préchargements client sur l'App Router utilisent désormais l'attribut priority (PR)
  • [Amélioration] Next.js fournit désormais une fonction unstable_rethrow pour relancer les erreurs internes de Next.js dans l'App Router (PR)
  • [Amélioration] unstable_after peut désormais être utilisé dans les pages statiques (PR)
  • [Amélioration] Si un composant next/dynamic est utilisé pendant le SSR, le chunk sera préchargé (PR)
  • [Amélioration] L'option esmExternals est désormais supportée sur l'App Router (PR)
  • [Amélioration] L'option experimental.allowDevelopmentBuild peut être utilisée pour autoriser NODE_ENV=development avec next build à des fins de débogage (PR)
  • [Amélioration] Les transformations Server Action sont désormais désactivées dans le Pages Router (PR)
  • [Amélioration] Les workers de build empêcheront désormais le build de rester bloqué lorsqu'ils se terminent (PR)
  • [Amélioration] Lors d'une redirection depuis une Server Action, les revalidations s'appliqueront correctement (PR)
  • [Amélioration] Les paramètres dynamiques sont désormais gérés correctement pour les routes parallèles sur l'Edge Runtime (PR)
  • [Amélioration] Les pages statiques respecteront désormais staleTime après le chargement initial (PR)
  • [Amélioration] vercel/og mis à jour avec un correctif de fuite mémoire (PR)
  • [Amélioration] Mise à jour des timings pour permettre l'utilisation de packages comme msw pour le mock d'APIs (PR)
  • [Amélioration] Les pages prérendues doivent utiliser staleTime statique (PR)

Pour en savoir plus, consultez le guide de mise à niveau.

Contributeurs

Next.js est le résultat du travail combiné de plus de 3 000 développeurs individuels, de partenaires industriels comme Google et Meta, et de notre équipe principale chez Vercel. Cette version a été rendue possible par :

Un grand merci à @AbhiShake1, @Aerilym, @AhmedBaset, @AnaTofuZ, @Arindam200, @Arinji2, @ArnaudFavier, @ArnoldVanN, @Auxdible, @B33fb0n3, @Bhavya031, @Bjornnyborg, @BunsDev, @CannonLock, @CrutchTheClutch, @DeepakBalaraman, @DerTimonius, @Develliot, @EffectDoplera, @Ehren12, @Ethan-Arrowood, @FluxCapacitor2, @ForsakenHarmony, @Francoscopic, @Gomah, @GyoHeon, @Hemanshu-Upadhyay, @HristovCodes, @HughHzyb, @IAmKushagraSharma, @IDNK2203, @IGassmann, @ImDR, @IncognitoTGT, @Jaaneek, @JamBalaya56562, @Jeffrey-Zutt, @JohnGemstone, @JoshuaKGoldberg, @Julian-Louis, @Juneezee, @KagamiChan, @Kahitar, @KeisukeNagakawa, @KentoMoriwaki, @Kikobeats, @KonkenBonken, @Kuboczoch, @Lada496, @LichuAcu, @LorisSigrist, @Lsnsh, @Luk-z, @Luluno01, @M-YasirGhaffar, @Maaz-Ahmed007, @Manoj-M-S, @ManuLpz4, @Marukome0743, @MaxLeiter, @MehfoozurRehman, @MildTomato, @MonstraG, @N2D4, @NavidNourani, @Nayeem-XTREME, @Netail, @NilsJacobsen, @Ocheretovich, @OlyaPolya, @PapatMayuri, @PaulAsjes, @PlagueFPS, @ProchaLu, @Pyr33x, @QiuranHu, @RiskyMH, @Sam-Phillemon9493, @Sayakie, @Shruthireddy04, @SouthLink, @Strift, @SukkaW, @Teddir, @Tim-Zj, @TrevorSayre, @Unsleeping, @Willem-Jaap, @a89529294, @abdull-haseeb, @abhi12299, @acdlite, @actopas, @adcichowski, @adiguno, @agadzik, @ah100101, @akazwz, @aktoriukas, @aldosch, @alessiomaffeis, @allanchau, @alpedia0, @amannn, @amikofalvy, @anatoliik-lyft, @anay-208, @andrii-bodnar, @anku255, @ankur-dwivedi, @aralroca, @archanaagivale30, @arlyon, @atik-persei, @avdeev, @baeharam, @balazsorban44, @bangseongbeom, @begalinsaf, @bennettdams, @bewinsnw, @bgw, @blvdmitry, @bobaaaaa, @boris-szl, @bosconian-dynamics, @brekk, @brianshano, @cfrank, @chandanpasunoori, @chentsulin, @chogyejin, @chrisjstott, @christian-bromann, @codeSTACKr, @coderfin, @coltonehrman, @controversial, @coopbri, @creativoma, @crebelskydico, @crutchcorn, @darthmaim, @datner, @davidsa03, @delbaoliveira, @devjiwonchoi, @devnyxie, @dhruv-kaushik, @dineshh-m, @diogocapela, @dnhn, @domdomegg, @domin-mnd, @dvoytenko, @ebCrypto, @ekremkenter, @emmerich, @flybayer, @floriangosse, @forsakenharmony, @francoscopic, @frys, @gabrielrolfsen, @gaojude, @gdborton, @greatvivek11, @gnoff, @guisehn, @GyoHeon, @hamirmahal, @hiro0218, @hirotomoyamada, @housseindjirdeh, @hungdoansy, @huozhi, @hwangstar156, @iampoul, @ianmacartney, @icyJoseph, @ijjk, @imddc, @imranolas, @iscekic, @jantimon, @jaredhan418, @jeanmax1me, @jericopulvera, @jjm2317, @jlbovenzo, @joelhooks, @joeshub, @jonathan-ingram, @jonluca, @jontewks, @joostmeijles, @jophy-ye, @jordienr, @jordyfontoura, @kahlstrm, @karlhorky, @karlkeefer, @kartheesan05, @kdy1, @kenji-webdev, @kevva, @khawajaJunaid, @kidonng, @kiner-tang, @kippmr, @kjac, @kjugi, @kshehadeh, @kutsan, @kwonoj, @kxlow, @leerob, @lforst, @li-jia-nan, @liby, @lonr, @lorensr, @lovell, @lubieowoce, @luciancah, @luismiramirez, @lukahartwig, @lumirlumir, @luojiyin1987, @mamuso, @manovotny, @marlier, @mauroaccornero, @maxhaomh, @mayank1513, @mcnaveen, @md-rejoyan-islam, @mehmetozguldev, @mert-duzgun, @mirasayon, @mischnic, @mknichel, @mobeigi, @molebox, @mratlamwala, @mud-ali, @n-ii-ma, @n1ckoates, @nattui, @nauvalazhar, @neila-a, @neoFinch, @niketchandivade, @nisabmohd, @none23, @notomo, @notrab, @nsams, @nurullah, @okoyecharles, @omahs, @paarthmadan, @pathliving, @pavelglac, @penicillin0, @phryneas, @pkiv, @pnutmath, @qqww08, @r34son, @raeyoung-kim, @remcohaszing, @remorses, @rezamauliadi, @rishabhpoddar, @ronanru, @royalfig, @rubyisrust, @ryan-nauman, @ryohidaka, @ryota-murakami, @s-ekai, @saltcod, @samcx, @samijaber, @sean-rallycry, @sebmarkbage, @shubh73, @shuding, @sirTangale, @sleevezip, @slimbde, @soedirgo, @sokra, @sommeeeer, @sopranopillow, @souporserious, @srkirkland, @steadily-worked, @steveluscher, @stipsan, @styfle, @stylessh, @syi0808, @symant233, @tariknh, @theoludwig, @timfish, @timfuhrmann, @timneutkens, @tknickman, @todor0v, @tokkiyaa, @torresgol10, @tranvanhieu01012002, @txxxxc, @typeofweb, @unflxw, @unstubbable, @versecafe, @vicb, @vkryachko, @wbinnssmith, @webtinax, @weicheng95, @wesbos, @whatisagi, @wiesson, @woutvanderploeg, @wyattjoh, @xiaohanyu, @xixixao, @xugetsu, @yosefbeder, @ypessoa, @ytori, @yunsii, @yurivangeffen, @z0n, @zce, @zhawtof, @zsh77, et @ztanner pour leur aide !