BackRetour au blog

Next.js 12

Next.js 12 introduit un tout nouveau compilateur Rust, le Middleware (bêta), le support de React 18, le support natif des ESM, les imports par URL, les React Server Components (alpha), et bien plus encore !

Comme nous l'avons annoncé lors du Next.js Conf, Next.js 12 est notre plus grande version jamais publiée :

Mettez à jour dès maintenant en exécutant npm i next@latest.

Builds plus rapides et Fast Refresh avec le compilateur Rust

Nous voulons que chaque application Next.js se build plus rapidement en production et obtienne un retour instantané en développement local. Next.js 12 inclut un tout nouveau compilateur Rust qui tire parti de la compilation native.

Notre compilateur Rust est construit sur SWC, une plateforme open source pour la nouvelle génération d'outils rapides. Nous avons optimisé le bundling et la compilation avec un rafraîchissement ~3x plus rapide en local et des builds ~5x plus rapides pour la production. Les autres améliorations et fonctionnalités incluent :

Résultats de l'utilisation du nouveau compilateur Rust avec des codebases Next.js volumineuses.

Résultats de l'utilisation du nouveau compilateur Rust avec des codebases Next.js volumineuses.

  • Améliorations supplémentaires de vitesse pour les gros codebases : Nous avons validé le compilateur Rust avec certaines des plus grandes codebases Next.js au monde.
  • Meilleure observabilité des performances : Next.js affiche maintenant les temps de Fast Refresh dans la console pour la compilation côté client et serveur, y compris le nombre de modules et fichiers compilés.
  • Améliorations sous-jacentes de webpack : Nous avons apporté de nombreuses améliorations à webpack, notamment en optimisant Fast Refresh et en rendant les entrées à la demande plus fiables.

La compilation avec Rust est 17x plus rapide que Babel et activée par défaut avec Next.js 12, remplaçant la transformation des fichiers JavaScript et TypeScript. Cela signifiait que nous devions porter les transformations Babel de Next.js en Rust, y compris un tout nouveau parseur CSS en Rust utilisé pour implémenter la transformation styled-jsx.

Le nouveau compilateur Rust est rétrocompatible. Si vous avez une configuration Babel existante, vous serez automatiquement désactivé. Nous prévoyons de porter bientôt le parsing pour des bibliothèques populaires comme styled-components, emotion et relay. Si vous utilisez une configuration Babel personnalisée, partagez votre configuration.

Vous pouvez aussi opter pour l'utilisation du compilateur Rust pour la minification. C'est 7x plus rapide que Terser. La minification est optionnelle jusqu'à ce qu'elle soit validée de manière approfondie car elle remplace une infrastructure vieille de plusieurs années.

next.config.js
module.exports = {
  swcMinify: true,
};

En plus d'embaucher DongYoon Kang, le créateur de SWC, et Maia Teegarden, une contributrice à Parcel, nous continuons à investir dans l'écosystème Rust. Si vous avez de l'expérience avec Rust, postulez pour rejoindre notre équipe.

Pour plus d'informations, regardez notre démo du Next.js Conf.

Présentation du Middleware

Le Middleware vous permet d'utiliser du code plutôt que de la configuration. Cela vous donne une flexibilité totale dans Next.js car vous pouvez exécuter du code avant qu'une requête ne soit complétée. En fonction de la requête entrante de l'utilisateur, vous pouvez modifier la réponse en réécrivant, redirigeant, ajoutant des en-têtes ou même en streamant du HTML.

Le Middleware vous offre une flexibilité totale dans Next.js.

Le Middleware vous offre une flexibilité totale dans Next.js.

Le Middleware peut être utilisé pour tout ce qui partage une logique pour un ensemble de pages, notamment :

Le Middleware utilise un runtime strict qui supporte les APIs Web standard comme fetch. Cela fonctionne nativement avec next start, ainsi que sur les plateformes Edge comme Vercel, qui utilisent Edge Middleware.

Pour utiliser le Middleware dans Next.js, vous pouvez créer un fichier pages/_middleware.js. Dans cet exemple, nous utilisons l'API Web standard Response (MDN) :

pages/_middleware.js
export function middleware(req, ev) {
  return new Response('Hello, world!');
}

Pour plus d'informations, regardez notre démo du Next.js Conf et consultez la documentation.

Préparation pour React 18

React 18 ajoutera des fonctionnalités comme Suspense, le batching automatique des mises à jour, des APIs comme startTransition, et une nouvelle API de streaming pour le rendu serveur avec support de React.lazy.

Nous avons travaillé en étroite collaboration avec l'équipe React chez Facebook pour préparer Next.js pour React 18 alors qu'il se dirige vers une version stable. Nous rendons ces fonctionnalités disponibles pour essai aujourd'hui dans Next.js 12 sous un drapeau expérimental.

Terminal
npm install react@alpha react-dom@alpha

Streaming côté serveur

Les fonctionnalités concurrentes dans React 18 incluent un support natif pour Suspense côté serveur et le streaming SSR. Cela vous permet de rendre des pages côté serveur en utilisant le streaming HTTP. C'est une fonctionnalité expérimentale dans Next.js 12, mais une fois activée, le SSR utilisera le même runtime strict que le Middleware.

Pour l'activer, utilisez le drapeau expérimental concurrentFeatures: true :

next.config.js
module.exports = {
  experimental: {
    concurrentFeatures: true,
  },
};

Composants Serveur React

Les composants serveur React (React Server Components) nous permettent de tout rendre, y compris les composants eux-mêmes, sur le serveur. Cela diffère fondamentalement du rendu côté serveur (SSR) où vous pré-générez du HTML sur le serveur. Avec les composants serveur, aucun JavaScript côté client n'est nécessaire, ce qui accélère le rendu des pages. Cela améliore l'expérience utilisateur de votre application, en combinant les meilleurs aspects du rendu côté serveur avec l'interactivité côté client.

next.config.js
module.exports = {
  experimental: {
    concurrentFeatures: true,
    serverComponents: true,
  },
};

Next.js vous permet désormais de récupérer des données au niveau du composant, le tout exprimé en JSX. En utilisant les composants serveur React, nous pouvons simplifier les choses. Les fonctions spéciales comme getServerSideProps ou getStaticProps ne sont plus nécessaires. Cela s'aligne avec le modèle des Hooks React qui consiste à colocaliser la récupération de données avec vos composants.

Vous pouvez renommer n'importe quelle page Next.js en .server.js pour créer un composant serveur et importer des composants client directement dans vos composants serveur. Ces composants client s'hydrateront et deviendront interactifs, vous permettant ainsi d'ajouter des fonctionnalités comme les votes.

Nous travaillons actuellement sur Suspense côté serveur, l'hydratation sélective et le rendu en streaming dans Next.js, et nous partagerons nos progrès dans un futur article de blog.

Un grand merci à nos collaborateurs Kara Erickson et Gerald Monaco de l'équipe Google Aurora pour leur travail sur React 18 et les composants serveur.

Pour plus d'informations, regardez notre démo de Next.js Conf et consultez la documentation.

Support des modules ES et imports par URL

Les modules ES apportent un système de modules officiel et standardisé à JavaScript. Ils sont pris en charge par tous les principaux navigateurs ainsi que par Node.js.

Cette norme fait avancer l'écosystème web en permettant des tailles de paquets et des bundles JavaScript plus petits, ce qui conduit finalement à une meilleure expérience utilisateur. Alors que l'écosystème JavaScript passe de Common JS (l'ancienne norme) aux modules ES, nous nous engageons à aider les développeurs à adopter progressivement ces améliorations sans changements cassants inutiles.

Depuis Next.js 11.1, nous avons ajouté un support expérimental pour les modules ES qui sont prioritaires par rapport aux modules CommonJS. Dans Next.js 12, c'est désormais le comportement par défaut. L'importation de modules NPM qui ne fournissent que CommonJS est toujours prise en charge.

Imports par URL

Next.js 12 inclut un support expérimental pour l'importation de modules ES via des URL, sans installation ni étape de build séparée.

Les imports par URL vous permettent d'utiliser n'importe quel paquet directement via une URL. Cela permet à Next.js de traiter les ressources HTTP(S) distantes exactement comme des dépendances locales.

Si un import par URL est détecté, Next.js générera un fichier next.lock pour suivre les ressources distantes. Les imports par URL sont mis en cache localement pour garantir que vous pouvez continuer à travailler hors ligne. Next.js prend en charge les imports par URL côté client et serveur.

Pour activer cette fonctionnalité, ajoutez les préfixes URL autorisés dans next.config.js :

next.config.js
module.exports = {
  experimental: {
    urlImports: ['https://cdn.skypack.dev'],
  },
};

Ensuite, vous pouvez importer des modules directement depuis des URL :

import confetti from 'https://cdn.skypack.dev/canvas-confetti';

Tout CDN qui sert des modules ES fonctionnera, y compris les outils de no-code et de design comme Framer :

Pour plus d'informations, regardez notre démo de Next.js Conf et consultez la documentation.

Fallback ISR conscient des bots

Actuellement, la régénération statique incrémentielle (ISR) avec fallback: true affiche un état de fallback avant de rendre le contenu de la page lors de la première requête vers une page qui n'a pas encore été générée. Pour empêcher le chargement de la page (rendu côté serveur), vous deviez utiliser fallback: 'blocking'.

Dans Next.js 12, les robots d'indexation (par exemple les bots de recherche) rendront automatiquement les pages ISR côté serveur en utilisant fallback: true, tout en conservant le comportement précédent de l'état de fallback pour les User-Agents qui ne sont pas des robots. Cela empêche les robots d'indexer les états de chargement.

Images plus petites avec AVIF

L'API intégrée d'optimisation d'images prend désormais en charge les images AVIF, permettant des images 20 % plus petites qu'avec WebP.

Les images AVIF peuvent prendre plus de temps à optimiser que WebP, c'est pourquoi nous rendons cette fonctionnalité optionnelle en utilisant la nouvelle propriété images.formats dans next.config.js :

next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
  },
};

Cette liste de formats est utilisée pour déterminer le format d'image optimisé à la demande en fonction de l'en-tête Accept de la requête. Comme AVIF est en premier, il sera servi si le navigateur prend en charge AVIF. Sinon, WebP sera servi si le navigateur prend en charge WebP. Si aucun de ces formats n'est pris en charge, le format d'image original sera servi.

Traçage des fichiers de sortie

Dans Next.js 8, nous avons introduit l'option target. Cela permettait de générer les pages Next.js sous forme de bundles JavaScript autonomes en regroupant toutes les dépendances à l'aide de webpack pendant la build. Nous avons rapidement réalisé que ce n'était pas idéal et avons plutôt créé @vercel/nft. @vercel/nft est utilisé depuis plus de 2 ans sur tous les déploiements de la plateforme Vercel.

Maintenant, nous intégrons ces améliorations directement dans le framework Next.js par défaut, pour toutes les plateformes de déploiement, offrant une approche bien meilleure que l'option target.

Next.js 12 trace automatiquement les fichiers nécessaires pour chaque page et route API en utilisant @vercel/nft, et génère ces résultats de traçage à côté de la sortie de next build, permettant aux intégrateurs d'exploiter les traces que Next.js fournit automatiquement.

Ces changements optimisent également les applications déployées avec des outils comme Docker via next start. En tirant parti de @vercel/nft, nous pourrons rendre la sortie de Next.js autonome à l'avenir. Aucune dépendance ne devra être installée pour exécuter l'application, réduisant considérablement la taille de l'image Docker.

L'intégration de @vercel/nft dans Next.js remplace l'approche target, rendant target obsolète dans Next.js 12. Consultez la documentation pour plus d'informations.

Autres améliorations

  • L'ajout de pages/_app.js ou pages/_document.js à votre application remplace maintenant automatiquement la version intégrée sans nécessiter de redémarrage du CLI Next.js.
  • L'intégration ESLint prend désormais en charge le linting fichier par fichier dans next lint avec le flag --file.
  • Next.js 12 prend désormais en charge la définition d'un chemin personnalisé pour tsconfig.json.
  • next.config.mjs est maintenant pris en charge pour écrire la configuration sous forme de modules ES.
  • Les requêtes en vol sont maintenant dédupliquées pour getStaticProps.
  • La vérification des pages statiques s'exécute maintenant à l'aide d'un pool de workers partagé.
  • Fast Refresh utilise maintenant une connexion WebSocket au lieu d'une connexion EventSource.

Changements cassants

  • Après avoir rendu webpack 5 par défaut dans Next.js 11, nous avons officiellement supprimé webpack 4. Nous avons travaillé en étroite collaboration avec la communauté pour assurer une transition en douceur vers webpack 5.
  • target dans next.config.js n'est plus nécessaire.
  • next/image utilise maintenant un span comme élément englobant au lieu d'un div.
  • La version minimale de Node.js est passée de 12.0.0 à 12.22.0, qui est la première version de Node.js avec support natif des modules ES.

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

Communauté

Il y a cinq ans, nous avons publié Next.js au public. Nous avions pour objectif de construire un framework React sans configuration qui simplifie votre expérience de développement. Avec le recul, c'est incroyable de voir comment la communauté a grandi, et ce que nous avons pu livrer ensemble. Continuons sur cette lancée.

Next.js est le résultat du travail combiné de plus de 1 800 développeurs individuels, de partenaires industriels comme Google et Facebook, et de notre équipe principale.

Cette version a été rendue possible grâce aux contributions de : @ka2n, @housseindjirdeh, @rojserbest, @lobsterkatie, @thibautsabot, @javivelasco, @sokra, @rishabhpoddar, @kdy1, @huozhi, @georgegach, @ionut-botizan, @paul-creates, @TimBarley, @kimizuy, @devknoll, @matamatanot, @christianvuerings, @pgrodrigues, @mohamedbhy, @AlfonzAlfonz, @kara, @molebox, @angelopoole, @oste, @genetschneider, @jantimon, @kyliau, @mxschmitt, @PhattOZ, @finn-orsini, @kriswuollett, @harryheman, @GustavoEdinger, @AryanBeezadhur, @Blevs, @colevscode, @atcastle, @ijjk, @velocity23, @jonowu, @timneutkens, @whitep4nth3r, @micro-chipset, @TyMick, @padmaia, @arthurdenner, @vitorbal, @zNeb, @jacksonhardaker, @shuding, @kylemh, @Bundy-Mundi, @ctjlewis, @thien-do, @leerob, @Dev-CasperTheGhost, @janicklas-ralph, @rezathematic, @KonstHardy, @fracture91, @lorensr, @Sheraff, @HaNdTriX, @emilio, @oluan, @ddzieduch, @colinclerk, @x4th, @volcareso, @oiva, @sinchang, @scottrepreneur, @smakosh, @catnose99, @adrienharnay, @donsn, @andersonleite, @msp5382, @tim-hanssen, @appsplash99, @alexvilchis, @RobEasthope, @royal, @Perry-Olsson, @well-balanced, @mrmckeb, @buraksakalli, @espipj, @prateekbh, @AleksaC, @eungyeole, et @rgabs