Next.js 15 Release Candidate (RC)

Die Next.js 15 Release Candidate (RC) ist nun verfügbar. Diese Vorabversion ermöglicht es Ihnen, die neuesten Funktionen vor der kommenden stabilen Version zu testen.

• React: Unterstützung für React 19 RC, React Compiler (Experimentell) und Verbesserungen bei Hydration-Fehlern
• Caching: fetch-Anfragen, GET-Route-Handler und Client-Navigations werden standardmäßig nicht mehr gecached
• Partielles Prerendering (Experimentell): Neue Layout- und Seitenkonfigurationsoption für schrittweise Einführung
• next/after (Experimentell): Neue API zur Code-Ausführung nach Abschluss des Response-Streamings
• create-next-app: Aktualisiertes Design und neue Flag für Turbopack in der lokalen Entwicklung
• Bündelung externer Pakete (Stabil): Neue Konfigurationsoptionen für App- und Pages-Router

Testen Sie die Next.js 15 RC jetzt:

npm install next@rc react@rc react-dom@rc

React 19 RC

Der Next.js App Router basiert auf dem React-Canary-Kanal für Frameworks, was Entwicklern ermöglicht hat, diese neuen React-APIs vor der v19-Veröffentlichung zu nutzen und Feedback zu geben.

Next.js 15 RC unterstützt nun React 19 RC, das neue Funktionen für Client und Server wie Actions enthält.

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

Hinweis: Einige Drittanbieter-Bibliotheken sind möglicherweise noch nicht mit React 19 kompatibel.

React Compiler (Experimentell)

Der React Compiler ist ein neuer experimenteller Compiler, der vom React-Team bei Meta entwickelt wurde. Der Compiler versteht Ihren Code durch sein tiefes Verständnis der JavaScript-Semantik und der React-Regeln, was ihm ermöglicht, automatische Optimierungen vorzunehmen. Der Compiler reduziert den manuellen Aufwand für Memoization durch APIs wie useMemo und useCallback - was den Code einfacher, wartbarer und weniger fehleranfällig macht.

Mit Next.js 15 haben wir die Unterstützung für den React Compiler hinzugefügt.

Installieren Sie babel-plugin-react-compiler:

npm install babel-plugin-react-compiler

Fügen Sie dann die Option experimental.reactCompiler in next.config.js hinzu:

const nextConfig = {
  experimental: {
    reactCompiler: true,
  },
};
 
module.exports = nextConfig;

Optional können Sie den Compiler im "Opt-in"-Modus wie folgt konfigurieren:

const nextConfig = {
  experimental: {
    reactCompiler: {
      compilationMode: 'annotation',
    },
  },
};
 
module.exports = nextConfig;

Hinweis: Der React Compiler kann derzeit in Next.js nur über ein Babel-Plugin verwendet werden, was zu längeren Build-Zeiten führen kann.

Erfahren Sie mehr über den React Compiler und die verfügbaren Next.js-Konfigurationsoptionen.

Verbesserungen bei Hydration-Fehlern

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

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

Next.js 15 RC hat dies wie folgt verbessert:

Caching-Änderungen

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 Drittanbieter-Bibliotheken, die fetch verwenden, neu bewertet.

Mit Next.js 15 ändern wir die Caching-Standards für fetch-Anfragen, GET-Route-Handler und 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 die Caching-Funktionen in Next.js in den kommenden Monaten weiter verbessern und mehr Details in der Next.js 15 GA-Ankündigung teilen.

fetch-Anfragen werden standardmäßig nicht mehr gecached

Next.js verwendet die Web-fetch-API Cache-Option, um zu konfigurieren, wie eine serverseitige Fetch-Anfrage mit dem persistenten HTTP-Cache des Frameworks interagiert:

fetch('https://...', { cache: 'force-cache' | 'no-store' });

• no-store - holt eine Ressource bei jeder Anfrage vom Remote-Server und aktualisiert den Cache nicht
• force-cache - holt eine Ressource aus dem Cache (falls vorhanden) oder vom Remote-Server und aktualisiert den Cache

In Next.js 14 wurde standardmäßig force-cache verwendet, wenn keine cache-Option angegeben war, es sei denn, eine dynamische Funktion oder dynamische Konfigurationsoption wurde verwendet.

In Next.js 15 wird standardmäßig no-store verwendet, wenn keine cache-Option angegeben ist. Das bedeutet, dass Fetch-Anfragen standardmäßig nicht gecached werden.

Sie können das Caching von fetch-Anfragen weiterhin aktivieren durch:

• Setzen der cache-Option auf force-cache in einem einzelnen fetch-Aufruf
• Setzen der dynamic-Route-Konfigurationsoption auf 'force-static' für eine einzelne Route
• Setzen der fetchCache-Route-Konfigurationsoption auf 'default-cache', um alle fetch-Anfragen in einem Layout oder einer Seite auf force-cache zu setzen, es sei denn, sie geben explizit ihre eigene cache-Option an

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 dynamische Konfigurationsoption. In Next.js 15 werden GET-Funktionen standardmäßig nicht gecached.

Sie können das Caching weiterhin über eine statische 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 speichert Page-Komponenten standardmäßig nicht mehr

In Next.js 14.2.0 haben wir ein experimentelles staleTimes-Flag eingeführt, um die Konfiguration des Router Caches anzupassen.

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 der Page-Komponenten widerspiegelt, die durch die Navigation aktiv werden. Es gibt jedoch wichtige Verhaltensweisen, die unverändert bleiben:

• Daten von Shared Layouts werden nicht erneut vom Server abgerufen, um Partial Rendering weiterhin zu unterstützen.
• Die Navigation über Zurück/Vorwärts wird weiterhin aus dem Cache wiederhergestellt, um sicherzustellen, dass der Browser die Scroll-Position beibehalten kann.
• Loading.js bleibt für 5 Minuten (oder den Wert der staleTimes.static-Konfiguration) im Cache gespeichert.

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

const nextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 30,
    },
  },
};
 
module.exports = nextConfig;

Inkrementelle Einführung von Partial Prerendering (Experimentell)

In Next.js 14 haben wir Partial Prerendering (PPR) eingeführt – eine Optimierung, die statisches und dynamisches Rendering auf derselben Seite kombiniert.

Next.js verwendet standardmäßig statisches Rendering, es sei denn, Sie verwenden dynamische Funktionen wie cookies(), headers() oder ungecachte Datenanfragen. Diese APIs aktivieren dynamisches Rendering für eine gesamte Route. Mit PPR können Sie jede dynamische UI in eine Suspense-Boundary einwickeln. Wenn eine neue Anfrage eingeht, liefert Next.js sofort eine statische HTML-Shell und rendert und streamt dann die dynamischen Teile in derselben HTTP-Anfrage.

Um eine schrittweise Einführung zu ermöglichen, haben wir eine experimental_ppr-Route-Konfigurationsoption hinzugefügt, um bestimmte Layouts und Pages für PPR zu aktivieren:

import { Suspense } from "react"
import { StaticComponent, DynamicComponent } from "@/app/ui"
 
export const experimental_ppr = true
 
export default function Page() {
  return {
     <>
	     <StaticComponent />
	     <Suspense fallback={...}>
		     <DynamicComponent />
	     </Suspense>
     </>
  };
}

Um die neue Option zu verwenden, müssen Sie die experimental.ppr-Konfiguration in Ihrer next.config.js-Datei auf 'incremental' setzen:

const nextConfig = {
  experimental: {
    ppr: 'incremental',
  },
};
 
module.exports = nextConfig;

Sobald alle Segmente PPR aktiviert haben, können Sie den ppr-Wert sicher auf true setzen und für die gesamte App und alle zukünftigen Routen aktivieren.

Wir werden mehr über unseren PPR-Fahrplan in unserem Next.js 15 GA-Blogpost teilen.

Erfahren Sie mehr über Partial Prerendering.

Code nach einer Antwort mit next/after ausführen (Experimentell)

Bei der Verarbeitung einer Benutzeranfrage 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 Synchronisation mit externen Systemen durchführen.

Da diese Aufgaben nicht direkt mit der Antwort zusammenhängen, sollte der Benutzer nicht auf deren Abschluss warten müssen. Die Verzögerung 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 es ermöglicht, Arbeit zu planen, die nach dem Ende des Antwort-Streamings 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:

const nextConfig = {
  experimental: {
    after: true,
  },
};
 
module.exports = nextConfig;

Dann importieren Sie 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 next/after.

create-next-app-Updates

Für Next.js 15 haben wir create-next-app mit einem neuen Design aktualisiert.

Bei der Ausführung von create-next-app gibt es eine neue Abfrage, ob Sie Turbopack für die lokale Entwicklung aktivieren möchten (Standard ist Nein).

✔ Möchten Sie Turbopack für next dev verwenden? … Nein / Ja

Das --turbo-Flag kann verwendet werden, um Turbopack zu aktivieren.

npx create-next-app@rc --turbo

Um den Einstieg in ein neues Projekt noch einfacher zu gestalten, wurde ein neues --empty-Flag zur CLI hinzugefügt. Dadurch werden überflüssige Dateien und Stile entfernt, was zu einer minimalen "Hello World"-Seite führt.

npx create-next-app@rc --empty

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 deaktivieren.

Im Pages Router werden externe Pakete standardmäßig nicht gebündelt, aber Sie können eine Liste von Paketen angeben, die mit der bestehenden transpilePackages-Option gebündelt werden sollen. 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, um das standardmäßige automatische Bündeln des App Routers nachzuahmen. Sie können dann bei Bedarf serverExternalPackages verwenden, um bestimmte Pakete auszuschließen.

const nextConfig = {
  // Externe Pakete im Pages Router automatisch bündeln:
  bundlePagesRouterDependencies: true,
  // Bestimmte Pakete für App und Pages Router vom Bündeln ausschließen:
  serverExternalPackages: ['package-name'],
};
 
module.exports = nextConfig;

Erfahren Sie mehr über die Optimierung externer Pakete.

Weitere Änderungen

• [Breaking] Mindestversion von React ist jetzt 19 RC
• [Breaking] next/image: Entfernung von squoosh zugunsten von sharp als optionale 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, um nicht empfohlene React-API-Imports zu beschränken (PR)
• [Breaking] next/font: Unterstützung für das externe @next/font-Paket entfernt (PR)
• [Breaking] next/font: Entfernung der font-family-Hashing (PR)
• [Breaking] Caching: force-dynamic setzt jetzt standardmäßig no-store für den Fetch-Cache (PR)
• [Breaking] Konfiguration: Aktivierung von swcMinify (PR), missingSuspenseWithCSRBailout (PR) und outputFileTracing (PR) als Standard und Entfernung veralteter Optionen
• [Breaking] Entfernung der Auto-Instrumentierung für Speed Insights (muss jetzt das dedizierte @vercel/speed-insights-Paket verwenden) (PR)
• [Breaking] Entfernung der .xml-Erweiterung für dynamische Sitemap-Routen und Angleichung der Sitemap-URLs zwischen Entwicklung und Produktion (PR)
• [Verbesserung] Metadaten: Aktualisierte Fallbacks für Umgebungsvariablen für metadataBase bei Hosting auf Vercel (PR)
• [Verbesserung] Behebung von Tree-Shaking mit gemischten Namespace- und benannten Imports aus optimizePackageImports (PR)
• [Verbesserung] Parallel Routes: Bereitstellung nicht übereinstimmender Catch-All-Routen mit allen bekannten Parametern (PR)
• [Verbesserung] Konfiguration bundlePagesExternals ist jetzt stabil und wurde in bundlePagesRouterDependencies umbenannt
• [Verbesserung] Konfiguration serverComponentsExternalPackages ist jetzt stabil und wurde in serverExternalPackages umbenannt
• [Verbesserung] create-next-app: Neue Projekte ignorieren standardmäßig alle .env-Dateien (PR)
• [Dokumentation] Verbesserte Authentifizierungsdokumentation (PR)
• [Dokumentation] @next/env-Paket (PR)

Um mehr zu erfahren, lesen Sie den Upgrade-Guide.

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:

• Das Next.js-Team: Andrew, Balazs, Ethan, Janka, Jiachi, Jimmy, JJ, Josh, Sam, Sebastian, Sebbie, Shu, Steven, Tim, Wyatt und Zack.
• Das Turbopack-Team: Alex, Benjamin, Donny, Leah, Maia, OJ, Tobias und Will.
• Next.js Docs: Delba, Steph, Michael, Anthony und Lee.

Ein riesiges Dankeschön an @devjiwonchoi, @ijjk, @Ethan-Arrowood, @sokra, @kenji-webdev, @wbinnssmith, @huozhi, @domdomegg, @samcx, @Jaaneek, @evanwinter, @wyattjoh, @kdy1, @balazsorban44, @feedthejim, @ztanner, @ForsakenHarmony, @kwonoj, @delbaoliveira, @stipsan, @leerob, @shuding, @xiaohanyu, @timneutkens, @dvoytenko, @bobaaaaa, @bgw, @gaspar09, @souporserious, @unflxw, @kiner-tang, @Ehren12, @EffectDoplera, @IAmKushagraSharma, @Auxdible, @sean-rallycry, @Jeffrey-Zutt, @eps1lon, @jeanmax1me, @unstubbable, @NilsJacobsen, @PaulAsjes, @adiguno, @ryan-nauman, @zsh77, @KagamiChan, @steveluscher, @MehfoozurRehman, @vkryachko, @chentsulin, @samijaber, @begalinsaf, @FluxCapacitor2, @lukahartwig, @brianshano, @pavelglac, @styfle, @symant233, @HristovCodes, @karlhorky, @jonluca, @jonathan-ingram, @mknichel, @sopranopillow, @Gomah, @imddc, @notrab, @gabrielrolfsen, @remorses, @AbhiShake1, @agadzik, @ryota-murakami, @rishabhpoddar, @rezamauliadi, @IncognitoTGT, @webtinax, @BunsDev, @nisabmohd, @z0n, @bennettdams, @joeshub, @n1ckoates, @srkirkland, @RiskyMH, @coopbri, @okoyecharles, @diogocapela, @dnhn, @typeofweb, @davidsa03, @imranolas, @lubieowoce, @maxhaomh, @mirasayon, @blvdmitry, @hwangstar156, @lforst, @emmerich, @christian-bromann, @Lsnsh, @datner, @hiro0218, @flybayer, @ianmacartney, @ypessoa, @ryohidaka, @icyJoseph, @Arinji2, @lovell, @nsams, @Nayeem-XTREME, @JamBalaya56562, @Arindam200, @gaojude, @qqww08, @todor0v, @coltonehrman und @wiesson für ihre Hilfe!