BackZurück zum Blog

Next.js 15

Next.js 15 bringt Unterstützung für React 19, Verbesserungen beim Caching, eine stabile Version von Turbopack in der Entwicklung, neue APIs und mehr.

Next.js 15 ist offiziell stabil und produktionsbereit. Diese Version baut auf den Updates von RC1 und RC2 auf. Wir haben uns stark auf Stabilität konzentriert und dabei einige spannende Updates hinzugefügt, die Sie lieben werden. Probieren Sie Next.js 15 heute aus:

terminal
# Verwenden Sie die neue automatische Upgrade-CLI
npx @next/codemod@canary upgrade latest
 
# ...oder führen Sie das Upgrade manuell durch
npm install next@latest react@rc react-dom@rc

Wir freuen uns auch, mehr über die kommenden Neuerungen auf der Next.js Conf diesen Donnerstag, den 24. Oktober, zu berichten.

Hier sind die Neuerungen in Next.js 15:

Einfache Upgrades mit der @next/codemod CLI

Wir liefern mit jedem größeren Next.js-Release Codemods (automatisierte Code-Transformationen) mit, um das Upgrade von Breaking Changes zu erleichtern.

Um Upgrades noch einfacher zu machen, haben wir eine verbesserte Codemod-CLI veröffentlicht:

Terminal
npx @next/codemod@canary upgrade latest

Dieses Tool hilft Ihnen, Ihre Codebasis auf die neuesten stabilen oder Vorabversionen zu aktualisieren. Die CLI aktualisiert Ihre Abhängigkeiten, zeigt verfügbare Codemods an und führt Sie durch deren Anwendung.

Der canary-Tag verwendet die neueste Version des Codemods, während latest die Next.js-Version angibt. Wir empfehlen, die Canary-Version des Codemods zu verwenden, selbst wenn Sie auf die neueste Next.js-Version upgraden, da wir planen, das Tool basierend auf Ihrem Feedback weiter zu verbessern.

Erfahren Sie mehr über die Next.js Codemod CLI.

Async Request APIs (Breaking Change)

Beim traditionellen Server-Side Rendering wartet der Server auf eine Anfrage, bevor er Inhalte rendert. Nicht alle Komponenten hängen jedoch von anfragespezifischen Daten ab, daher ist es unnötig, auf die Anfrage zu warten, um sie zu rendern. Idealerweise würde der Server so viel wie möglich vorbereiten, bevor eine Anfrage eintrifft. Um dies zu ermöglichen und die Grundlage für zukünftige Optimierungen zu schaffen, müssen wir wissen, wann auf die Anfrage gewartet werden muss.

Daher machen wir APIs, die von anfragespezifischen Daten abhängen – wie headers, cookies, params und searchParams – asynchron.

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

Dies ist eine Breaking Change und betrifft folgende APIs:

  • cookies
  • headers
  • draftMode
  • params in layout.js, page.js, route.js, default.js, generateMetadata und generateViewport
  • searchParams in page.js

Für eine einfachere Migration können diese APIs vorübergehend synchron aufgerufen werden, zeigen aber Warnungen in Entwicklung und Produktion bis zum nächsten Major-Release an. Ein Codemod steht zur Automatisierung der Migration zur Verfügung:

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

Für Fälle, in denen das Codemod Ihren Code nicht vollständig migrieren kann, lesen Sie bitte die Upgrade-Anleitung. Wir haben auch ein Beispiel bereitgestellt, wie Sie eine Next.js-Anwendung auf die neuen APIs migrieren können.

Caching-Semantik

Der Next.js App Router startete mit vordefinierten Caching-Standards. Diese waren darauf ausgelegt, die performanteste Option standardmäßig bereitzustellen, mit der Möglichkeit, bei Bedarf zu deaktivieren.

Basierend auf Ihrem Feedback haben wir unsere Caching-Heuristiken und deren Interaktion mit Projekten wie Partial Prerendering (PPR) und Drittanbieterbibliotheken, die fetch verwenden, neu bewertet.

Mit Next.js 15 ändern wir die Caching-Standardeinstellung für GET-Route-Handler und den Client-Router-Cache von standardmäßig gecached zu standardmäßig nicht gecached. Wenn Sie das vorherige Verhalten beibehalten möchten, können Sie weiterhin Caching aktivieren.

Wir werden das Caching in Next.js in den kommenden Monaten weiter verbessern und bald mehr Details teilen.

GET-Route-Handler werden standardmäßig nicht mehr gecached

In Next.js 14 wurden Route-Handler, die die GET-HTTP-Methode verwendeten, standardmäßig gecached, es sei denn, sie verwendeten eine dynamische Funktion oder eine dynamische Konfigurationsoption. In Next.js 15 werden GET-Funktionen standardmäßig nicht gecached.

Sie können Caching weiterhin mit einer statischen Route-Konfigurationsoption wie export dynamic = 'force-static' aktivieren.

Spezielle Route-Handler wie sitemap.ts, opengraph-image.tsx und icon.tsx sowie andere Metadaten-Dateien bleiben standardmäßig statisch, es sei denn, sie verwenden dynamische Funktionen oder dynamische Konfigurationsoptionen.

Client-Router-Cache cached Page-Komponenten standardmäßig nicht mehr

In Next.js 14.2.0 haben wir ein experimentelles staleTimes-Flag eingeführt, um eine benutzerdefinierte Konfiguration des Router-Caches zu ermöglichen.

In Next.js 15 bleibt dieses Flag weiterhin verfügbar, aber wir ändern das Standardverhalten, sodass Page-Segmente einen staleTime von 0 haben. Das bedeutet, dass beim Navigieren durch Ihre App der Client immer die neuesten Daten von den Page-Komponenten widerspiegelt, die Teil der Navigation werden. Es gibt jedoch wichtige Verhaltensweisen, die unverändert bleiben:

  • Geteilte Layout-Daten werden nicht erneut vom Server abgerufen, um weiterhin Partial Rendering zu unterstützen.
  • Back/Forward-Navigation wird weiterhin aus dem Cache wiederhergestellt, um sicherzustellen, dass der Browser die Scroll-Position wiederherstellen kann.
  • loading.js bleibt für 5 Minuten (oder den Wert der staleTimes.static-Konfiguration) gecached.

Sie können das vorherige Client-Router-Cache-Verhalten aktivieren, indem Sie folgende Konfiguration setzen:

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

React 19

Als Teil des Next.js 15-Releases haben wir uns entschieden, uns mit dem bevorstehenden Release von React 19 zu synchronisieren.

In Version 15 verwendet der App Router React 19 RC, und wir haben auch Rückwärtskompatibilität für React 18 mit dem Pages Router basierend auf Community-Feedback hinzugefügt. Wenn Sie den Pages Router verwenden, können Sie so auf React 19 upgraden, wenn Sie bereit sind.

Obwohl React 19 noch in der RC-Phase ist, haben unsere umfangreichen Tests in realen Anwendungen und unsere enge Zusammenarbeit mit dem React-Team uns Vertrauen in dessen Stabilität gegeben. Die zentralen Breaking Changes wurden gut getestet und werden bestehende App-Router-Nutzer nicht beeinträchtigen. Daher haben wir uns entschieden, Next.js 15 jetzt als stabil zu veröffentlichen, damit Ihre Projekte vollständig auf React 19 GA vorbereitet sind.

Um den Übergang so reibungslos wie möglich zu gestalten, haben wir Codemods und automatisierte Tools bereitgestellt, um die Migration zu erleichtern.

Lesen Sie die Next.js 15 Upgrade-Anleitung, die React 19 Upgrade-Anleitung und sehen Sie sich die React Conf Keynote an, um mehr zu erfahren.

Pages Router mit React 18

Next.js 15 behält die Rückwärtskompatibilität für den Pages Router mit React 18 bei, sodass Benutzer React 18 weiterhin verwenden können, während sie von den Verbesserungen in Next.js 15 profitieren.

Seit dem ersten Release Candidate (RC1) haben wir unseren Fokus auf die Unterstützung von React 18 basierend auf Community-Feedback erweitert. Diese Flexibilität ermöglicht es Ihnen, Next.js 15 zu übernehmen, während Sie den Pages Router mit React 18 verwenden, und gibt Ihnen mehr Kontrolle über Ihren Upgrade-Pfad.

Hinweis: Obwohl es möglich ist, den Pages Router mit React 18 und den App Router mit React 19 in derselben Anwendung zu betreiben, empfehlen wir dieses Setup nicht. Dies könnte zu unvorhersehbarem Verhalten und Typinkonsistenzen führen, da sich die zugrunde liegenden APIs und Rendering-Logiken zwischen den beiden Versionen möglicherweise nicht vollständig decken.

React Compiler (Experimentell)

Der React Compiler ist ein neuer experimenteller Compiler, der vom React-Team bei Meta entwickelt wurde. Der Compiler versteht Ihren Code auf tiefgreifende Weise durch sein Verständnis von plain JavaScript-Semantik und den Regeln von React, was es ihm ermöglicht, automatische Optimierungen an Ihrem Code vorzunehmen. Der Compiler reduziert die Menge an manueller Memoization, die Entwickler durch APIs wie useMemo und useCallback durchführen müssen – was den Code einfacher, wartbarer und weniger fehleranfällig macht.

Mit Next.js 15 haben wir Unterstützung für den React Compiler hinzugefügt. Erfahren Sie mehr über den React Compiler und die verfügbaren Next.js-Konfigurationsoptionen.

Hinweis: Der React Compiler ist derzeit nur als Babel-Plugin verfügbar, was zu langsameren Entwicklungs- und Build-Zeiten führen wird.

Verbesserungen bei Hydration-Fehlern

Next.js 14.1 hat Verbesserungen bei Fehlermeldungen und Hydration-Fehlern eingeführt. Next.js 15 baut darauf auf, indem es eine verbesserte Ansicht für Hydration-Fehler hinzufügt. Hydration-Fehler zeigen nun den Quellcode des Fehlers mit Vorschlägen zur Behebung des Problems an.

Hier ein Beispiel für eine Hydration-Fehlermeldung in Next.js 14.1:

Hydration-Fehlermeldung in Next.js 14.1

Next.js 15 hat dies verbessert zu:

Verbesserte Hydration-Fehlermeldung in Next.js 15

Turbopack Dev

Wir freuen uns, bekannt zu geben, dass next dev --turbo nun stabil und bereit ist, um Ihre Entwicklungserfahrung zu beschleunigen. Wir haben es verwendet, um auf vercel.com, nextjs.org, v0 und all unseren anderen Anwendungen mit großem Erfolg zu iterieren.

Beispielsweise haben wir bei vercel.com, einer großen Next.js-Anwendung, folgende Verbesserungen festgestellt:

  • Bis zu 76,7 % schnellere lokale Serverstartzeit.
  • Bis zu 96,3 % schnellere Code-Updates mit Fast Refresh.
  • Bis zu 45,8 % schnellere initiale Route-Kompilierung ohne Caching (Turbopack hat noch kein Disk-Caching).

Mehr über Turbopack Dev erfahren Sie in unserem neuen Blogbeitrag.

Statische Route-Indikator

Next.js zeigt nun während der Entwicklung einen Statischen Route-Indikator an, um Ihnen zu helfen, statische von dynamischen Routen zu unterscheiden. Dieser visuelle Hinweis erleichtert die Leistungsoptimierung, indem Sie verstehen, wie Ihre Seiten gerendert werden.

Sie können auch die next build-Ausgabe verwenden, um die Rendering-Strategie für alle Routen anzuzeigen.

Dieses Update ist Teil unserer Bemühungen, die Beobachtbarkeit in Next.js zu verbessern, um Entwicklern das Überwachen, Debuggen und Optimieren ihrer Anwendungen zu erleichtern. Wir arbeiten auch an dedizierten Entwickler-Tools, weitere Details folgen bald.

Erfahren Sie mehr über den Statischen Route-Indikator, der deaktiviert werden kann.

Code-Ausführung nach einer Antwort mit unstable_after (Experimentell)

Bei der Verarbeitung einer Benutzeranforderung führt der Server normalerweise Aufgaben aus, die direkt mit der Berechnung der Antwort zusammenhängen. Möglicherweise müssen Sie jedoch Aufgaben wie Protokollierung, Analysen und die Synchronisierung mit anderen externen Systemen durchführen.

Da diese Aufgaben nicht direkt mit der Antwort zusammenhängen, sollte der Benutzer nicht auf deren Abschluss warten müssen. Das Verschieben der Arbeit nach der Antwort an den Benutzer stellt eine Herausforderung dar, da serverlose Funktionen die Berechnung unmittelbar nach dem Schließen der Antwort beenden.

after() ist eine neue experimentelle API, die dieses Problem löst, indem sie Ihnen ermöglicht, Arbeit zu planen, die nach dem Ende des Antwort-Streams verarbeitet wird, sodass sekundäre Aufgaben ohne Blockierung der primären Antwort ausgeführt werden können.

Um sie zu verwenden, fügen Sie experimental.after zu next.config.js hinzu:

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

Importieren Sie dann die Funktion in Server Components, Server Actions, Route Handlers oder Middleware.

import { unstable_after as after } from 'next/server';
import { log } from '@/app/utils';
 
export default function Layout({ children }) {
  // Sekundäre Aufgabe
  after(() => {
    log();
  });
 
  // Primäre Aufgabe
  return <>{children}</>;
}

Erfahren Sie mehr über unstable_after.

instrumentation.js (Stabil)

Die instrumentation-Datei mit der register()-API ermöglicht es Benutzern, in den Next.js-Server-Lebenszyklus einzugreifen, um die Leistung zu überwachen, Fehlerquellen zu verfolgen und sich tief mit Observability-Bibliotheken wie OpenTelemetry zu integrieren.

Diese Funktion ist nun stabil, und die experimental.instrumentationHook-Konfigurationsoption kann entfernt werden.

Zusätzlich haben wir mit Sentry an der Gestaltung eines neuen onRequestError-Hooks zusammengearbeitet, der verwendet werden kann, um:

  • Wichtigen Kontext über alle auf dem Server ausgelösten Fehler zu erfassen, einschließlich:
    • Router: Pages Router oder App Router
    • Server-Kontext: Server Component, Server Action, Route Handler oder Middleware
  • Die Fehler an Ihren bevorzugten Observability-Provider zu melden.
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() {
  // Initialisieren Sie das SDK Ihres bevorzugten Observability-Providers
}

Erfahren Sie mehr über die onRequestError-Funktion.

<Form>-Komponente

Die neue <Form>-Komponente erweitert das HTML-<form>-Element um Prefetching, Client-seitige Navigation und progressive Verbesserung.

Sie ist nützlich für Formulare, die zu einer neuen Seite navigieren, wie z.B. ein Suchformular, das zu einer Ergebnisseite führt.

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>
  );
}

Die <Form>-Komponente bietet:

  • Prefetching: Wenn das Formular im Blickfeld ist, werden das Layout und die Loading-UI vorab geladen, was die Navigation beschleunigt.
  • Client-seitige Navigation: Bei der Übermittlung werden gemeinsame Layouts und der Client-seitige Zustand erhalten.
  • Progressive Verbesserung: Wenn JavaScript noch nicht geladen wurde, funktioniert das Formular dennoch über eine vollständige Seitennavigation.

Bisher erforderte die Umsetzung dieser Features viel manuellen Boilerplate-Code. Beispiel:

Beispiel

// Hinweis: Dies ist zur Demonstration gekürzt.
// Nicht für den Einsatz in Produktionscode empfohlen.
 
'use client'
 
import { useEffect } from 'react'
import { useRouter } from 'next/navigation'
 
export default function Form(props) {
  const action = props.action
  const router = useRouter()
 
  useEffect(() => {
    // Wenn das Formular-Ziel eine URL ist, diese vorab laden
    if (typeof action === 'string') {
      router.prefetch(action)
    }
  }, [action, router])
 
  function onSubmit(event) {
    event.preventDefault()
 
    // Alle Formularfelder erfassen und eine `router.push` mit den URL-kodierten Daten auslösen
    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} />
}

Erfahren Sie mehr über die <Form>-Komponente.

Unterstützung für next.config.ts

Next.js unterstützt nun den TypeScript-Dateityp next.config.ts und stellt einen NextConfig-Typ für Autovervollständigung und typsichere Optionen bereit:

next.config.ts
import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  /* Konfigurationsoptionen hier */
};
 
export default nextConfig;

Erfahren Sie mehr über die TypeScript-Unterstützung in Next.js.

Verbesserungen für Self-Hosting

Beim Self-Hosting von Anwendungen benötigen Sie möglicherweise mehr Kontrolle über Cache-Control-Direktiven.

Ein häufiger Anwendungsfall ist die Steuerung des stale-while-revalidate-Zeitraums für ISR-Seiten. Wir haben zwei Verbesserungen implementiert:

  1. Sie können nun den expireTime-Wert in next.config konfigurieren. Dies war zuvor die experimental.swrDelta-Option.
  2. Der Standardwert wurde auf ein Jahr aktualisiert, um sicherzustellen, dass die meisten CDNs die stale-while-revalidate-Semantik wie vorgesehen anwenden können.

Wir überschreiben außerdem keine benutzerdefinierten Cache-Control-Werte mehr mit unseren Standardwerten, was volle Kontrolle und Kompatibilität mit jedem CDN-Setup ermöglicht.

Schließlich haben wir die Bildoptimierung beim Self-Hosting verbessert. Bisher empfahlen wir die Installation von sharp zur Optimierung von Bildern auf Ihrem Next.js-Server. Diese Empfehlung wurde manchmal übersehen. Mit Next.js 15 müssen Sie sharp nicht mehr manuell installieren – Next.js verwendet sharp automatisch bei Verwendung von next start oder im Standalone-Output-Modus.

Mehr dazu erfahren Sie in unserem neuen Demo- und Tutorial-Video zum Self-Hosting von Next.js.

Erhöhte Sicherheit für Server Actions

Server Actions sind serverseitige Funktionen, die vom Client aufgerufen werden können. Sie werden definiert, indem die Direktive 'use server' am Anfang einer Datei hinzugefügt und eine asynchrone Funktion exportiert wird.

Auch wenn eine Server Action oder Hilfsfunktion nicht anderswo in Ihrem Code importiert wird, ist sie dennoch ein öffentlich zugänglicher HTTP-Endpunkt. Während dieses Verhalten technisch korrekt ist, kann es zur unbeabsichtigten Offenlegung solcher Funktionen führen.

Um die Sicherheit zu verbessern, haben wir folgende Erweiterungen eingeführt:

  • Dead-Code-Eliminierung: Nicht verwendete Server Actions haben keine IDs, die dem Client-seitigen JavaScript-Bundle ausgesetzt werden, was die Bundle-Größe reduziert und die Leistung verbessert.
  • Sichere Action-IDs: Next.js erzeugt nun nicht erratbare, nicht deterministische IDs, damit der Client die Server Action referenzieren und aufrufen kann. Diese IDs werden zwischen Builds periodisch neu berechnet, um die Sicherheit zu erhöhen.
// app/actions.js
'use server';
 
// Diese Action **wird** in unserer Anwendung verwendet, daher erstellt Next.js
// eine sichere ID, damit der Client die Server Action referenzieren
// und aufrufen kann.
export async function updateUserAction(formData) {}
 
// Diese Action **wird nicht** in unserer Anwendung verwendet, daher entfernt Next.js
// diesen Code automatisch während `next build`
// und erstellt keinen öffentlichen Endpunkt.
export async function deleteUserAction(formData) {}

Sie sollten Server Actions weiterhin als öffentliche HTTP-Endpunkte behandeln. Erfahren Sie mehr über das Sichern von Server Actions.

Optimierung des Bundlings externer Pakete (Stabil)

Das Bündeln externer Pakete kann die Cold-Start-Leistung Ihrer Anwendung verbessern. Im App Router werden externe Pakete standardmäßig gebündelt, und Sie können bestimmte Pakete mit der neuen serverExternalPackages-Konfigurationsoption ausschließen.

Im Pages Router werden externe Pakete standardmäßig nicht gebündelt, aber Sie können eine Liste der zu bündelnden Pakete mit der bestehenden transpilePackages-Option angeben. Mit dieser Konfigurationsoption müssen Sie jedes Paket einzeln angeben.

Um die Konfiguration zwischen App und Pages Router zu vereinheitlichen, führen wir eine neue Option ein, bundlePagesRouterDependencies, die dem standardmäßigen automatischen Bündeln des App Routers entspricht. Sie können dann serverExternalPackages verwenden, um bei Bedarf bestimmte Pakete auszuschließen.

next.config.ts
const nextConfig = {
  // Automatisches Bündeln externer Pakete im Pages Router:
  bundlePagesRouterDependencies: true,
  // Bestimmte Pakete für App und Pages Router vom Bündeln ausschließen:
  serverExternalPackages: ['package-name'],
};
 
export default nextConfig;

Erfahren Sie mehr über die Optimierung externer Pakete.

ESLint 9-Unterstützung

Next.js 15 führt auch Unterstützung für ESLint 9 ein, nachdem ESLint 8 am 5. Oktober 2024 das Ende seiner Lebensdauer erreicht hat.

Um einen reibungslosen Übergang zu gewährleisten, bleibt Next.js abwärtskompatibel, was bedeutet, dass Sie weiterhin entweder ESLint 8 oder 9 verwenden können.

Wenn Sie auf ESLint 9 upgraden und wir feststellen, dass Sie das neue Konfigurationsformat noch nicht übernommen haben, wendet Next.js automatisch den ESLINT_USE_FLAT_CONFIG=false-Workaround an, um die Migration zu erleichtern.

Zusätzlich werden veraltete Optionen wie —ext und —ignore-path beim Ausführen von next lint entfernt. Beachten Sie, dass ESLint diese älteren Konfigurationen in ESLint 10 schließlich nicht mehr zulassen wird, daher empfehlen wir, Ihre Migration bald zu beginnen.

Weitere Details zu diesen Änderungen finden Sie im Migrationsleitfaden.

Im Rahmen dieses Updates haben wir auch eslint-plugin-react-hooks auf v5.0.0 aktualisiert, das neue Regeln für die Verwendung von React Hooks einführt. Alle Änderungen finden Sie im Changelog für [email protected].

Entwicklungs- und Build-Verbesserungen

Server Components HMR

Während der Entwicklung werden Server Components bei Speicherung neu ausgeführt. Das bedeutet, dass alle fetch-Anfragen an Ihre API-Endpunkte oder Drittanbieter-Dienste ebenfalls aufgerufen werden.

Um die lokale Entwicklungsleistung zu verbessern und potenzielle Kosten für abrechenbare API-Aufrufe zu reduzieren, stellen wir nun sicher, dass Hot Module Replacement (HMR) fetch-Antworten von vorherigen Renderings wiederverwenden kann.

Erfahren Sie mehr über den Server Components HMR Cache.

Schnellere statische Generierung für den App Router

Wir haben die statische Generierung optimiert, um die Build-Zeiten zu verbessern, insbesondere für Seiten mit langsamen Netzwerkanfragen.

Bisher wurde unser statischer Optimierungsprozess zweimal durchgeführt – einmal zur Generierung von Daten für die clientseitige Navigation und ein zweites Mal zum Rendern des HTML für den ersten Seitenbesuch. Jetzt verwenden wir den ersten Render-Vorgang wieder, wodurch der zweite Durchlauf entfällt, was die Arbeitslast und Build-Zeiten reduziert.

Zusätzlich teilen sich die Worker für die statische Generierung nun den fetch-Cache über Seiten hinweg. Wenn ein fetch-Aufruf das Caching nicht deaktiviert, werden seine Ergebnisse von anderen Seiten wiederverwendet, die vom selben Worker bearbeitet werden. Dies reduziert die Anzahl der Anfragen für dieselben Daten.

Erweiterte Kontrolle über die statische Generierung (Experimentell)

Wir haben experimentelle Unterstützung für eine bessere Kontrolle über den statischen Generierungsprozess für fortgeschrittene Anwendungsfälle hinzugefügt, die von einer größeren Kontrolle profitieren würden.

Wir empfehlen, bei den aktuellen Standardeinstellungen zu bleiben, sofern Sie keine spezifischen Anforderungen haben, da diese Optionen zu erhöhtem Ressourcenverbrauch und potenziellen Speicherfehlern aufgrund erhöhter Parallelität führen können.

next.config.ts
const nextConfig = {
  experimental: {
    // wie oft Next.js fehlgeschlagene Seiten-Generierungsversuche wiederholt,
    // bevor der Build als fehlgeschlagen markiert wird
    staticGenerationRetryCount: 1
    // wie viele Seiten pro Worker verarbeitet werden
    staticGenerationMaxConcurrency: 8
    // die minimale Anzahl von Seiten, bevor ein neuer Export-Worker gestartet wird
    staticGenerationMinPagesPerWorker: 25
  },
}
 
export default nextConfig;

Erfahren Sie mehr über die Optionen für die statische Generierung.

Weitere Änderungen

  • [Breaking] next/image: Entfernung von squoosh zugunsten von sharp als optionaler Abhängigkeit (PR)
  • [Breaking] next/image: Standard-Content-Disposition auf attachment geändert (PR)
  • [Breaking] next/image: Fehler bei src mit führenden oder nachfolgenden Leerzeichen (PR)
  • [Breaking] Middleware: Anwendung der react-server-Bedingung zur Einschränkung nicht empfohlener React-API-Imports (PR)
  • [Breaking] next/font: Entfernung der Unterstützung für das externe @next/font-Paket (PR)
  • [Breaking] next/font: Entfernung des font-family-Hashings (PR)
  • [Breaking] Caching: force-dynamic setzt nun standardmäßig no-store für den Fetch-Cache (PR)
  • [Breaking] Config: Aktivierung von swcMinify (PR), missingSuspenseWithCSRBailout (PR) und outputFileTracing (PR) als Standard und Entfernung veralteter Optionen
  • [Breaking] Entfernung der Auto-Instrumentierung für Speed Insights (nun muss das dedizierte @vercel/speed-insights-Paket verwendet werden) (PR)
  • [Breaking] Entfernung der .xml-Erweiterung für dynamische Sitemap-Routen und Angleichung der Sitemap-URLs zwischen Entwicklung und Produktion (PR)
  • [Breaking] Wir haben das Exportieren von export const runtime = "experimental-edge" im App Router als veraltet markiert. Benutzer sollten nun auf export const runtime = "edge" wechseln. Wir haben einen Codemod hinzugefügt, um dies durchzuführen (PR)
  • [Breaking] Aufrufe von revalidateTag und revalidatePath während des Renderings lösen nun einen Fehler aus (PR)
  • [Breaking] Die Dateien instrumentation.js und middleware.js verwenden nun die mitgelieferten React-Pakete (PR)
  • [Breaking] Die mindestens erforderliche Node.js-Version wurde auf 18.18.0 aktualisiert (PR)
  • [Breaking] next/dynamic: Die veraltete suspense-Prop wurde entfernt, und wenn die Komponente im App Router verwendet wird, wird keine leere Suspense-Grenze mehr eingefügt (PR)
  • [Breaking] Beim Auflösen von Modulen in der Edge Runtime wird die worker-Modulbedingung nicht mehr angewendet (PR)
  • [Breaking] Verbot der Verwendung der ssr: false-Option mit next/dynamic in Server Components (PR)
  • [Verbesserung] Metadata: Aktualisierte Fallbacks für Umgebungsvariablen für metadataBase bei Hosting auf Vercel (PR)
  • [Verbesserung] Behebung des Tree-Shaking mit gemischten Namespace- und benannten Imports aus optimizePackageImports (PR)
  • [Verbesserung] Parallel Routes: Bereitstellung unpassender Catch-All-Routen mit allen bekannten Parametern (PR)
  • [Verbesserung] Die Config-Option bundlePagesExternals ist nun stabil und wurde in bundlePagesRouterDependencies umbenannt
  • [Verbesserung] Die Config-Option serverComponentsExternalPackages ist nun stabil und wurde in serverExternalPackages umbenannt
  • [Verbesserung] create-next-app: Neue Projekte ignorieren standardmäßig alle .env-Dateien (PR)
  • [Verbesserung] Die Optionen outputFileTracingRoot, outputFileTracingIncludes und outputFileTracingExcludes wurden von experimentell auf stabil hochgestuft (PR)
  • [Verbesserung] Vermeidung der Zusammenführung globaler CSS-Dateien mit CSS-Modul-Dateien tiefer in der Baumstruktur (PR)
  • [Verbesserung] Der Cache-Handler kann über die Umgebungsvariable NEXT_CACHE_HANDLER_PATH angegeben werden (PR)
  • [Verbesserung] Der Pages Router unterstützt nun sowohl React 18 als auch React 19 (PR)
  • [Verbesserung] Der Error Overlay zeigt nun eine Schaltfläche zum Kopieren der Node.js Inspector-URL an, wenn der Inspector aktiviert ist (PR)
  • [Verbesserung] Client-Prefetches im App Router verwenden nun das priority-Attribut (PR)
  • [Verbesserung] Next.js bietet nun eine unstable_rethrow-Funktion zum erneuten Auslösen interner Next.js-Fehler im App Router (PR)
  • [Verbesserung] unstable_after kann nun in statischen Seiten verwendet werden (PR)
  • [Verbesserung] Wenn eine next/dynamic-Komponente während SSR verwendet wird, wird der Chunk geprefetched (PR)
  • [Verbesserung] Die esmExternals-Option wird nun im App Router unterstützt (PR)
  • [Verbesserung] Die Option experimental.allowDevelopmentBuild kann verwendet werden, um NODE_ENV=development mit next build für Debugging-Zwecke zuzulassen (PR)
  • [Verbesserung] Die Server Action-Transforms sind nun im Pages Router deaktiviert (PR)
  • [Verbesserung] Build-Worker verhindern nun, dass der Build hängen bleibt, wenn sie beendet werden (PR)
  • [Verbesserung] Bei einer Weiterleitung von einer Server Action werden Revalidierungen nun korrekt angewendet (PR)
  • [Verbesserung] Dynamische Parameter werden nun korrekt für Parallel Routes in der Edge Runtime behandelt (PR)
  • [Verbesserung] Statische Seiten berücksichtigen nun staleTime nach dem initialen Laden (PR)
  • [Verbesserung] vercel/og mit einer Behebung für Memory Leaks aktualisiert (PR)
  • [Verbesserung] Aktualisierung der Patch-Zeiten zur Verwendung von Paketen wie msw für API-Mocking (PR)
  • [Verbesserung] Prerender-Seiten sollten statisches staleTime verwenden (PR)

Weitere Informationen finden Sie im Upgrade-Leitfaden.

Mitwirkende

Next.js ist das Ergebnis der gemeinsamen Arbeit von über 3.000 einzelnen Entwicklern, Industriepartnern wie Google und Meta und unserem Kernteam bei Vercel. Diese Version wurde ermöglicht durch:

Ein großes Dankeschön an @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, @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 und @ztanner für ihre Hilfe!