BackZurück zum Blog

Next.js 9

Next.js 9 bietet Unterstützung für TypeScript, Dynamisches Routing, API-Routen, Automatische Statische Optimierung und mehr!

Nach 70 Canary-Releases freuen wir uns, Next.js 9 mit folgenden Funktionen vorzustellen:

Wie immer haben wir sichergestellt, dass alle diese Vorteile abwärtskompatibel sind. Für die meisten Next.js-Anwendungen müssen Sie nur folgendes ausführen:

Terminal
npm i next@latest react@latest react-dom@latest

Es gibt nur wenige Fälle, in denen Änderungen am Code erforderlich sind. Weitere Informationen finden Sie im Upgrade-Leitfaden.

Seit unserem letzten Release haben Unternehmen wie IGN, Bang & Olufsen, Intercom, Buffer und Ferrari mit Next.js gestartet. Weitere Beispiele finden Sie in der Showcase!

Integrierte TypeScript-Unterstützung ohne Konfiguration

Vor einem Jahr führte Next.js 6 grundlegende TypeScript-Unterstützung über ein Plugin namens @zeit/next-typescript ein. Benutzer mussten außerdem ihre .babelrc anpassen und es in next.config.js aktivieren.

Bei korrekter Konfiguration ermöglichte das Plugin das Bauen von .ts- und .tsx-Dateien durch Next.js. Es integrierte jedoch keine Typüberprüfung, noch wurden Typen vom Next.js-Kern bereitgestellt. Dies bedeutete, dass ein Community-Paket separat in DefinitelyTyped gepflegt werden musste, das möglicherweise nicht mit Releases synchron war.

In Gesprächen mit vielen Benutzern, bestehenden und neuen, wurde klar, dass die meisten sehr daran interessiert waren, TypeScript zu verwenden. Sie wollten eine zuverlässigere und standardisierte Lösung für die einfache Integration von TypeScript in ihren bestehenden oder neuen Code.

Aus diesem Grund haben wir uns entschieden, die TypeScript-Unterstützung in den Next.js-Kern zu integrieren, die Entwicklererfahrung zu verbessern und den Prozess zu beschleunigen.

Automatisierte Einrichtung

Der Einstieg in TypeScript mit Next.js ist einfach: Benennen Sie jede Datei, Seite oder Komponente von .js in .tsx um und führen Sie dann next dev aus!

Dadurch erkennt Next.js, dass TypeScript in Ihrem Projekt verwendet wird. Die Next.js-CLI führt Sie durch die Installation der erforderlichen Typen für React und Node.js.

Next.js erstellt auch eine standardmäßige tsconfig.json mit sinnvollen Voreinstellungen, falls diese noch nicht vorhanden ist. Diese Datei ermöglicht eine integrierte Typüberprüfung in Editoren wie Visual Studio Code.

Automatisierte TypeScript-Einrichtung in Next.js 9

Integrierte Typüberprüfung

Next.js übernimmt die Typüberprüfung für Sie sowohl während der Entwicklung als auch beim Bau für die Produktion.

Während der Entwicklung zeigt Next.js Typfehler nach dem Speichern einer Datei an. Die Typüberprüfung erfolgt im Hintergrund, sodass Sie sofort mit Ihrer aktualisierten Anwendung im Browser interagieren können. Typfehler werden im Browser angezeigt, sobald sie verfügbar sind.

Entwicklungstypüberprüfung in Next.js 9

Next.js wird den Produktionsbuild (d.h. next build) automatisch fehlschlagen lassen, wenn Typfehler vorhanden sind. Dies hilft, das Ausliefern von fehlerhaftem Code in die Produktion zu verhindern.

Produktionstypüberprüfung in Next.js 9

Produktionstypüberprüfung in Next.js 9

Next.js-Kern in TypeScript geschrieben

In den letzten Monaten haben wir den größten Teil der Codebasis auf TypeScript migriert. Dies hat nicht nur unsere Codequalität gestärkt, sondern ermöglicht uns auch, Typen für alle Kernmodule bereitzustellen.

Wenn Sie beispielsweise next/link importieren, zeigen Editoren mit TypeScript-Unterstützung die erlaubten Eigenschaften und deren akzeptierte Werte an.

Next.js-Kerntypen

Next.js-Kerntypen

Dynamische Routensegmente

Dynamisches Routing (auch bekannt als URL Slugs oder Pretty/Clean URLs) war eine der ersten Feature-Anfragen auf GitHub nach der Veröffentlichung von Next.js vor 2,5 Jahren!

Das Problem wurde in Next.js 2.0 durch die Einführung der Custom-Server-API für die programmatische Verwendung von Next.js "gelöst". Dies ermöglichte die Verwendung von Next.js als Rendering-Engine, wodurch Abstraktionen und die Zuordnung eingehender URLs zum Rendern bestimmter Seiten ermöglicht wurden.

Wir sprachen mit Benutzern und untersuchten viele ihrer Anwendungen und stellten fest, dass viele von ihnen einen benutzerdefinierten Server hatten. Ein Muster zeigte sich: Der Hauptgrund für den benutzerdefinierten Server war dynamisches Routing.

Ein benutzerdefinierter Server bringt jedoch seine eigenen Fallstricke mit sich: Das Routing wird auf Serverebene statt auf Proxyebene behandelt, es wird als Monolith bereitgestellt und skaliert und ist anfällig für Leistungsprobleme.

Da ein benutzerdefinierter Server die gesamte Anwendung in einer Instanz verfügbar haben muss, ist die Bereitstellung in einer Serverless-Umgebung, die diese Probleme löst, typischerweise schwierig. Serverless-Anfragen werden auf Proxyebene geroutet und unabhängig skaliert/ausgeführt, um Leistungsengpässe zu vermeiden.

Darüber hinaus glauben wir, dass wir eine bessere Entwicklererfahrung bieten können! Ein Großteil der Next.js-Magie beginnt, wenn Sie eine Datei namens pages/blog.js erstellen und plötzlich eine Seite unter /blog verfügbar ist.

Warum sollte ein Benutzer einen eigenen Server erstellen und die programmatische API von Next.js lernen müssen, um eine Route wie /blog/my-first-post (/blog/:id) zu unterstützen?

Basierend auf diesem Feedback und dieser Vision begannen wir mit der Untersuchung von Routenzuordnungslösungen, die von dem geleitet wurden, was Benutzer bereits kannten: das pages/-Verzeichnis.

Erstellen einer dynamisch gerouteten Seite

Next.js unterstützt das Erstellen von Routen mit grundlegenden benannten Parametern, einem Muster, das durch path-to-regexp (die Bibliothek, die Express antreibt) populär gemacht wurde.

Das Erstellen einer Seite, die der Route /post/:pid entspricht, kann nun durch das Erstellen einer Datei in Ihrem pages-Verzeichnis mit dem Namen pages/post/[pid].js erreicht werden!

Next.js wird automatisch Anfragen wie /post/1, /post/hello-nextjs usw. abgleichen und die in pages/post/[pid].js definierte Seite rendern. Das übereinstimmende URL-Segment wird als Query-Parameter an Ihre Seite übergeben, mit dem Namen, der zwischen den [eckigen Klammern] angegeben ist.

Beispiel: Bei der folgenden Seite und der Anfrage /post/hello-nextjs wird das query-Objekt { pid: 'hello-nextjs' } sein:

static async getInitialProps({ query }) {
  // pid = 'hello-nextjs'
  const { pid } = query
 
  const postContent = await fetch(
    `https://api.example.com/post/${encodeURIComponent(pid)}`
  ).then(r => r.text())
 
  return { postContent }
}

Mehrere dynamische URL-Segmente werden ebenfalls unterstützt!

Die [param]-Syntax wird für Verzeichnis- und Dateinamen unterstützt, was bedeutet, dass die folgenden Beispiele funktionieren:

./pages/blog/[blogId]/comments/[commentId].js
./pages/posts/[pid]/index.js

Sie können mehr über diese Funktion in der Next.js-Dokumentation oder im Next.js Learn-Bereich lesen.

Automatische Statische Optimierung

Next.js führte die Unterstützung für die Generierung statischer Websites in v3 hinzu, die vor etwa zwei Jahren veröffentlicht wurde. Damals war dies das am häufigsten angefragte Feature für Next.js.

Und das aus gutem Grund: Es ist unbestreitbar, dass statische Websites schnell sind! Sie benötigen keine serverseitige Berechnung und können sofort vom CDN an den Endbenutzer gestreamt werden.

Die Wahl zwischen einer serverseitig gerenderten oder statisch generierten Anwendung war jedoch binär: Entweder Sie entschieden sich für Server-Side Rendering oder für statische Generierung. Es gab keinen Mittelweg.

In der Realität können Anwendungen unterschiedliche Anforderungen haben. Diese Anforderungen erfordern unterschiedliche Rendering-Strategien und Kompromisse.

Beispielsweise enthalten Startseiten und Marketingseiten typischerweise statische Inhalte und sind gute Kandidaten für statische Optimierung.

Andererseits kann ein Produkt-Dashboard von serverseitigem Rendering profitieren, bei dem die Daten häufig aktualisiert werden.

Wir begannen zu untersuchen, wie wir Benutzern das Beste aus beiden Welten bieten und standardmäßig schnell sein können. Wie könnten wir Benutzern statische Marketingseiten und dynamische serverseitig gerenderte Seiten bieten?

Ab Next.js 9 müssen Benutzer nicht mehr die Wahl zwischen vollständigem Server-Side Rendering oder statischem Export ihrer Anwendung treffen. Sie erhalten das Beste aus beiden Welten auf einer pro-Seite-Basis.

Automatischer partieller statischer Export

Es wurde eine Heuristik eingeführt, um automatisch zu bestimmen, ob eine Seite zu statischem HTML vorgerendert werden kann.

Diese Bestimmung erfolgt anhand der Frage, ob die Seite blockierende Datenanforderungen durch die Verwendung von getInitialProps hat.

Diese Heuristik ermöglicht es Next.js, hybride Anwendungen zu erstellen, die sowohl serverseitig gerenderte als auch statisch generierte Seiten enthalten.

Der integrierte Next.js-Server (next start) und die programmatische API (app.getRequestHandler()) unterstützen diese Build-Ausgabe transparent. Es ist keine Konfiguration oder spezielle Handhabung erforderlich.

Statisch generierte Seiten bleiben reaktiv: Next.js wird Ihre Anwendung clientseitig hydrieren, um ihr vollständige Interaktivität zu geben.

Darüber hinaus aktualisiert Next.js Ihre Anwendung nach der Hydratation, wenn die Seite von Query-Parametern in der URL abhängt.

Next.js zeigt Ihnen während der Entwicklung visuell an, ob eine Seite statisch generiert wird. Dieses visuelle Artefakt kann durch Klicken ausgeblendet werden.

Next.js-Statischer Optimierungsindikator

Next.js-Statischer Optimierungsindikator

Statisch generierte Seiten werden auch in der Next.js-Build-Ausgabe angezeigt:

Next.js-Build-Ausgabe-Typindikator

Next.js-Build-Ausgabe-Typindikator

API-Routen

In vielen Fällen benötigen Sie beim Erstellen von React-Anwendungen eine Art Backend. Entweder um Daten aus einer Datenbank abzurufen oder um von Benutzern bereitgestellte Daten zu verarbeiten (z.B. ein Kontaktformular).

Wir stellten fest, dass viele Benutzer, die ein Backend benötigten, ihre API mit einem benutzerdefinierten Server erstellten. Dabei stießen sie auf einige Probleme. Beispielsweise kompiliert Next.js keinen benutzerdefinierten Servercode, was bedeutet, dass Sie import / export oder TypeScript nicht verwenden konnten.

Aus diesem Grund implementierten viele Benutzer ihre eigene benutzerdefinierte Kompilierungspipeline auf dem benutzerdefinierten Server. Während dies ihr Ziel löste, ist es anfällig für viele Fallstricke: Beispielsweise war Tree Shaking für ihre gesamte Anwendung deaktiviert, wenn es falsch konfiguriert war.

Dies warf die Frage auf: Was, wenn wir die Entwicklererfahrung, die Next.js bietet, auch für den Aufbau von API-Backends bereitstellen?

Heute freuen wir uns, API-Routen vorzustellen, die beste Entwicklererfahrung von Next.js für den Aufbau Ihres Backends.

Um API-Routen zu verwenden, erstellen Sie ein Verzeichnis namens api/ innerhalb des pages/-Verzeichnisses.

Jede Datei in diesem Verzeichnis wird automatisch /api/<Ihre Route> zugeordnet, genauso wie andere Seiten-Dateien Routen zugeordnet werden.

Beispielsweise wird pages/api/contact.js auf /api/contact abgebildet.

Hinweis: API-Routen unterstützen auch Dynamische Routen!

Alle Dateien im pages/api/-Verzeichnis exportieren eine Request-Handler-Funktion anstelle einer React-Komponente:

export default function handle(req, res) {
  res.end('Hello World');
}

Im Allgemeinen nehmen API-Endpunkte einige eingehende Daten entgegen, z.B. die Query-String, den Request-Body oder Cookies, und antworten mit anderen Daten.

Bei der Untersuchung der Unterstützung von API-Routen in Next.js stellten wir fest, dass in vielen Fällen Benutzer die Node.js-Request- und Response-Objekte nicht direkt verwendeten. Stattdessen verwendeten sie eine Abstraktion, die von Serverbibliotheken wie Express bereitgestellt wird.

Der Grund dafür ist, dass die eingehenden Daten in vielen Fällen eine Form von Text sind, der zuerst geparst werden muss, um nützlich zu sein. Diese speziellen Serverbibliotheken helfen, die Last des manuellen Parsens der Daten zu entfernen, meist über Middlewares. Die am häufigsten verwendeten bieten das Parsen von Query-String, Body und Cookies, erfordern jedoch noch einige Einrichtung, um loszulegen.

API-Routen in Next.js werden diese Middlewares standardmäßig bereitstellen, damit Sie sofort produktiv API-Endpunkte erstellen können:

export default function handle(req, res) {
  console.log(req.body); // Der Request-Body
  console.log(req.query); // Der URL-Query-String
  console.log(req.cookies); // Die übergebenen Cookies
  res.end('Hello World');
}

Neben der Verwendung eingehender Daten gibt Ihr API-Endpunkt im Allgemeinen auch Daten zurück. Üblicherweise ist diese Antwort JSON. Next.js stellt standardmäßig res.json() bereit, um das Senden von Daten zu erleichtern:

export default function handle(req, res) {
  res.json({ title: 'Hello World' });
}

Wenn Sie Änderungen an API-Endpunkten in der Entwicklung vornehmen, wird der Code automatisch neu geladen, sodass kein Neustart des Servers erforderlich ist.

Produktionsoptimierungen

Next.js 9 wird <Link>-Komponenten automatisch prefetchen, sobald sie im Sichtbereich erscheinen.

Diese Funktion verbessert die Reaktionsfähigkeit Ihrer Anwendung, indem Navigationen zu neuen Seiten schneller werden.

Next.js verwendet einen Intersection Observer, um die notwendigen Assets im Hintergrund zu prefetchen.

Diese Anfragen haben niedrige Priorität und weichen fetch()- oder XHR-Anfragen aus. Next.js wird das automatische Prefetching vermeiden, wenn der Benutzer den Daten-Sparmodus aktiviert hat.

Sie können diese Funktion für selten besuchte Seiten deaktivieren, indem Sie die prefetch-Eigenschaft auf false setzen:

<Link href="/terms" prefetch={false}>
  <a>Nutzungsbedingungen</a>
</Link>

Optimiertes AMP standardmäßig

Next.js 9 rendert standardmäßig optimiertes AMP für AMP-first und hybride AMP-Seiten.

Während AMP-Seiten optional sind, optimiert Next.js automatisch deren Ausgabe. Diese Optimierungen können zu einer bis zu 50 % schnelleren Rendering-Geschwindigkeit führen!

Diese Änderung wurde durch die herausragende Arbeit von Sebastian Benz am AMP Optimizer ermöglicht.

Dead Code Elimination für typeof window-Zweige

Next.js 9 ersetzt typeof window während Server- und Client-Builds durch den entsprechenden Wert (undefined oder object). Diese Änderung ermöglicht es Next.js, toten Code automatisch aus Ihrer Produktionsanwendung zu entfernen.

Benutzer sollten eine Verringerung ihrer Client-seitigen Bundle-Größen feststellen, wenn sie Server-seitigen Code in getInitialProps oder anderen Teilen ihrer Anwendung haben.

Verbesserungen der Developer Experience

Kompilierungsindikator

In Versionen vor 9 war die einzige Möglichkeit, festzustellen, dass Hot Code Replacement stattfinden würde (und dass die Next.js-Compiler-Toolchain arbeitet), der Blick in die Entwicklerkonsole.

Oft schaut man jedoch auf das resultierende Rendering, was es schwierig macht zu erkennen, ob Next.js noch Kompilierungsarbeit leistet. Beispielsweise könnten Sie Änderungen an Seitenstilen vornehmen, die subtil sind, und Sie würden nicht sofort erkennen, ob sie aktualisiert wurden.

Aus diesem Grund haben wir ein RFC / "good first issue" erstellt, um mögliche Lösungen für das Problem der Arbeitsanzeige zu diskutieren.

Wir erhielten Feedback von vielen Designern und Entwicklern zum RFC, z.B. was sie bevorzugen und mögliche Richtungen für das Design des Indikators.

Rafael Almeida nutzte diese Gelegenheit, um mit unserem Team zusammenzuarbeiten und einen brandneuen Indikator zu implementieren, der jetzt standardmäßig in Next.js 9 verfügbar ist.

Wann immer Next.js Kompilierungsarbeit leistet, sehen Sie ein kleines Dreieck in der unteren rechten Ecke der Seite!

Next.js Kompilierungsindikator

Konsolenausgabe

Traditionell zeigte Next.js beim Entwickeln von Änderungen einen Kompilierungsindikator mit Ladebalken an und löschte kontinuierlich den Bildschirm, während Sie Änderungen vornahmen.

Dieses Verhalten verursachte einige Probleme. Am auffälligsten war, dass es die Konsolenausgabe sowohl Ihres Anwendungscodes löschte, z.B. wenn Sie console.log zu Ihren Komponenten hinzufügten, als auch bei der Verwendung externer Tools, die Log-Ausgaben zusammenfügen, wie die Vercel CLI oder docker-compose.

Ab Next.js 9 springt die Log-Ausgabe weniger und löscht den Bildschirm nicht mehr. Dies ermöglicht eine bessere Gesamterfahrung, da Ihr Terminal-Fenster relevantere Informationen enthält und weniger flackert, während Next.js besser mit Tools integriert, die Sie möglicherweise bereits verwenden.

Next.js Development-Konsolenausgabe

Besonderer Dank geht an Justin Chase für die Zusammenarbeit beim Ausgabelöschen.

Build-Ausgabe-Statistiken

Beim Erstellen Ihrer Anwendung für die Produktion mit next build erhalten Sie jetzt eine detaillierte Übersicht aller erstellten Seiten.

Jede Seite erhält automatisch einige Statistiken.

Die auffälligste ist die Bundle-Größe. Wenn Ihre Anwendung wächst, wachsen auch Ihre JavaScript-Bundles. Diese Build-Zeit-Anzeige hilft Ihnen, das Wachstum Ihrer Produktions-Bundles zu erkennen. In Zukunft können Sie auch Performance-Budgets für Seiten festlegen, die den Produktionsbuild fehlschlagen lassen.

Next.js erstellte Seitengröße

Next.js erstellte Seitengröße

Neben Bundle-Größen zeigen wir auch, wie viele Projektkomponenten und node_modules-Komponenten auf jeder Seite verwendet werden. Dies gibt einen Hinweis auf die Seitenkomplexität.

Next.js Seitenpaketzählung

Next.js Seitenpaketzählung

Jede Seite hat auch eine Anzeige, ob sie statisch optimiert oder server-seitig gerendert ist, da jede Seite sich unterschiedlich verhalten kann.

Next.js erstellter Seitentyp

Next.js erstellter Seitentyp

Seitenspezifisches Konfigurationsobjekt

Jede Seite kann jetzt ein Konfigurationsobjekt exportieren. Anfänglich ermöglicht diese Konfiguration das Opt-in für AMP, aber in Zukunft können Sie mehr seiten-spezifische Optionen konfigurieren.

pages/about.js
export const config = { amp: true };
 
export default function AboutPage(props) {
  return <h3>Meine AMP About-Seite!</h3>;
}

Um hybrides AMP-Rendering zu aktivieren, können Sie den Wert 'hybrid' verwenden:

pages/about.js
import { useAmp } from 'next/amp';
 
export const config = { amp: 'hybrid' };
 
export default function AboutPage(props) {
  const isAmp = useAmp();
  return <h3>Meine About-Seite!{isAmp ? <> Powered by AMP!</> : ''}</h3>;
}

Die withAmp Higher-Order-Komponente wurde zugunsten dieser neuen Konfiguration entfernt.

Wir haben einen Codemod bereitgestellt, der die Verwendung von withAmp automatisch in das neue Konfigurationsobjekt umwandelt. Sie können mehr darüber im Upgrade Guide lesen.

Codebase-Verbesserungen

Wir haben kürzlich einige Änderungen an unseren Tools vorgenommen, um eine bessere Erfahrung beim Beitrag zum Codebase zu bieten und die Stabilität zu gewährleisten, während die Codebase wächst.

Wie Sie im TypeScript-Abschnitt gelesen haben, ist der Next.js-Kern jetzt in TypeScript geschrieben, und Typen werden automatisch für Next.js-Anwendungen generiert. Neben dem Nutzen für Anwendungen, die mit Next.js erstellt werden, ist dies auch nützlich bei der Arbeit am Kern-Codebase, da Sie automatisch Typfehler und Autovervollständigung erhalten.

Next.js hatte bereits eine große Integrations-Test-Suite, die aus 50+ Next.js-Anwendungen mit Tests besteht, die gegen sie laufen. Diese Tests stellen sicher, dass beim Release einer neuen Version das Upgrade reibungslos verläuft, da die zuvor verfügbaren Features gegen dieselbe Test-Suite getestet wurden.

Die meisten unserer Tests sind Integrationstests, da sie in vielen Fällen "echte" Entwickler nachbilden, die Next.js in der Entwicklung verwenden. Beispielsweise haben wir Tests, die Änderungen an einer Next.js-Anwendung nachbilden, um zu sehen, ob Hot Module Replacement funktioniert.

Unsere Integrationstests basieren größtenteils auf Selenium WebDriver, das wir mit Chromedriver kombiniert haben, um in headless Chrome zu testen. Mit der Zeit traten jedoch Probleme in anderen Browsern auf, insbesondere in älteren Browsern wie Internet Explorer 11.

Da wir Selenium verwendeten, konnten wir unsere Tests automatisch in mehreren Browsern ausführen.

Derzeit führen wir unsere Test-Suite in Chrome, Firefox, Safari und Internet Explorer 11 aus.

Google Chrome Zusammenarbeit

Das Google Chrome-Team hat daran gearbeitet, Next.js durch Beiträge von RFCs und Pull-Requests zu verbessern.

Das Ziel dieser Zusammenarbeit sind groß angelegte Performance-Verbesserungen, die sich auf Bundle-Größen, Bootup- und Hydratationszeit konzentrieren.

Diese Änderungen werden beispielsweise die Erfahrung kleiner Websites verbessern, aber auch die massiver Anwendungen wie Hulu, Twitch und Deliveroo.

Module / Nomodule

Der erste Schwerpunkt liegt darauf, modernes JavaScript an Browser zu senden, die modernes JavaScript unterstützen.

Aktuell muss Next.js beispielsweise Polyfills für async/await-Syntax bereitstellen, da Code in Browsern ausgeführt werden könnte, die async/await nicht unterstützen, was zu Fehlern führen würde.

Next.js Module/Nomodule Zusammenarbeit RFC

Next.js Module/Nomodule Zusammenarbeit RFC

Um ältere Browser nicht zu brechen, während modernes JavaScript an Browser gesendet wird, die es unterstützen, wird Next.js das Module/Nomodule-Pattern nutzen. Das Module/Nomodule-Pattern bietet einen zuverlässigen Mechanismus, um modernes JavaScript an moderne Browser zu senden, während ältere Browser auf polyfilled ES5 zurückfallen können.

Die RFC für Module/Nomodule in Next.js kann hier gefunden werden.

Verbessertes Bundle-Splitting

Die aktuelle Bundle-Splitting-Strategie in Next.js basiert auf einem verhältnisbasierten Heuristik für die Aufnahme von Modulen in ein einzelnes "Commons"-Chunk. Da es nur sehr wenig Granularität gibt, da es nur ein Bundle gibt, wird Code entweder unnötig heruntergeladen (weil das Commons-Chunk Code enthalten könnte, der für eine bestimmte Route nicht erforderlich ist) oder der Code wird über mehrere Seiten-Bundles dupliziert.

Next.js Chunking Zusammenarbeit RFC

Next.js Chunking Zusammenarbeit RFC

Die RFC für verbessertes Bundle-Splitting kann hier gefunden werden.

Weitere Verbesserungen

Das Chrome-Team arbeitet auch an vielen anderen Optimierungen und Änderungen, die Next.js verbessern werden. RFCs dafür werden bald veröffentlicht.

Diese RFCs und Pull-Requests sind mit "Collaboration" gekennzeichnet, damit sie leicht im Next.js Issue-Tracker gefunden werden können.

Community

Wir freuen uns über das anhaltende Wachstum der Next.js-Community.

Dieses Release hatte über 65 Pull-Request-Autoren, die Kernverbesserungen oder Beispiele beigetragen haben.

Apropos Beispiele: Wir bieten jetzt über 200 Beispiele zur Integration von Next.js mit verschiedenen Bibliotheken und Technologien! Darunter die meisten CSS-in-JS- und Data-Fetching-Bibliotheken.

  • Wir hatten über 720 Mitwirkende, die mindestens 1 Commit beigetragen haben.
  • Auf GitHub wurde das Projekt über 38.600 Mal mit einem Stern versehen.
  • Über 3.400 Pull-Requests wurden seit dem ersten Release eingereicht, das sind über 800 seit dem letzten Major-Release!

Die Next.js-Community hat sich seit dem letzten Major-Release mit über 8.600 Mitgliedern verdoppelt. Kommen Sie zu uns!

Wir sind dankbar für unsere Community und all das externe Feedback und die Beiträge, die dieses Release geprägt haben.