PRNext 0.1.20: weniger Arbeit, mehr Kontrolle

#Starten Sie eine PPR-Seite, bevor der Knoten initialisiert wird

Eine PPR-Seite kombiniert einen während des Builds vorbereiteten Teil mit einer React-Fortsetzung, die dynamischen Inhalt erzeugt. Mit experimentell.nativePprShell kann der Rust-Server die zertifizierte Shell senden, bevor er den Node-Worker startet. Die Fortsetzung wird dann von demselben überprüften Artefakt aus fortgesetzt, anstatt eine unabhängige Anfangsantwort zu erstellen.

Dieser Pfad deckt konkrete App Router PPR-Dokument-GETs ohne Cookies, Autorisierung oder Abfragezeichenfolgen ab. Es erfordert CacheComponents. Anfragen, die Middleware, Rewrites, BasePath, CSP-Nonces oder Flight-Navigationsheader beinhalten, behalten das normale Rendering bei. Generische Parameter-Shells, Edge- und externe Caches bleiben ebenfalls außerhalb dieses Bereichs.

export default {
  cacheComponents: true,
  experimental: {
    nativePprShell: true
  }
};

Die Hülle muss intakt und nicht abgelaufen sein. Jede dauerhafte Invalidierung deaktiviert diese Build-Snapshot-Optimierung, auch über Neustarts hinweg, ohne PPR zu deaktivieren. Eine Anfrage, die bereits einen Snapshot verwendet, wird mit demselben Artefakt abgeschlossen. Antworten bleiben privat und werden nicht gespeichert: Dieser Mechanismus wandelt weder authentifizierte Seiten in öffentliche Inhalte um, noch ersetzt er die Autorisierung.

#Aktualisieren Sie die von einer Serveraktion betroffenen Routen

Das Bearbeiten einer Aktion, die von einem Abrechnungsbildschirm verwendet wird, muss nicht dazu führen, dass eine Registerkarte in einem nicht verwandten Teil des Produkts geöffnet wird. PRNext vergleicht Abhängigkeitsdiagramme vor und nach der Bearbeitung, um Routen zu identifizieren, die die Aktion direkt oder über ihre Abhängigkeiten importieren.

Wenn dieser Bereich festgelegt ist, kann die Entwicklungsaktualisierung auf die betroffenen Routen abzielen. Eine ersparte Registerkarte wendet ihre verzögerte Generierung an, bevor zu einer geänderten Route navigiert wird. Servergenerationen werden weiterhin als Ganzes veröffentlicht, und eine ausstehende Mutation wird nie wieder zusammen mit einer Aktualisierung übermittelt.

Ein unbekanntes oder unvollständiges Diagramm behält eine globale Aktualisierung bei. Konfigurations-, Routen-, Laufzeit- und Bindungsänderungen gehören ebenso dazu wie Middleware, Umschreibungen und bestimmte internationalisierte, parallele oder abfangende Routen. Das Targeting hängt vom festgelegten Umfang ab und nicht von einer Annahme über die gerade gespeicherte Datei.

#Wählen Sie Oxc für den React-Compiler, ohne ihn bei jedem Projekt installieren zu lassen

Der React-Compiler erhält neben dem bestehenden Babel-Backend ein experimentelles Oxc-Backend. Die Browserausgabe und das Rendern der App-Client-Komponentenserver verwenden separate Transformationen. Zu den Cache-Identitäten gehören das Backend, die Compiler-Version und der Client- oder SSR-Modus, sodass ein Ergebnis nicht im falschen Kontext wiederverwendet werden kann.

Babel bleibt die Standardeinstellung, wenn ReactCompiler aktiviert ist. Um Oxc auszuwählen, installieren Sie oxc-transform-react@0.157.0 explizit im Anwendungsprojekt mit aktivierten optionalen nativen Abhängigkeiten. Sogar ein globaler CLI löst diesen Compiler aus der Anwendung auf. Ein fehlender oder inkompatibler Compiler oder eine native Bindung führt zu einem expliziten Fehler; PRNext ändert Backends niemals stillschweigend.

export default {
  reactCompiler: {
    backend: 'oxc'
  }
};

Der Umfang bleibt förderfähige Projektkomponenten und Hooks. Serverkomponenten, Serveraktionen, npm-Pakete und das Seitenserverdiagramm bleiben außerhalb dieser Transformation. Quellkarten und Fast Refresh bleiben erhalten. Der prnext-Compilerbericht identifiziert die Diagnose auf Backend- und Dateiebene. Das Oxc API stellt nicht die Ereignisse bereit, die zum Zählen optimierter Funktionen erforderlich sind, wie dies bei Babel der Fall ist.

Projekte, die Babel beibehalten oder den React-Compiler deaktivieren, installieren Oxc nicht mehr für die interne Verwendung von PRNext. Die Auswahl eines in Rust geschriebenen Compilers stellt keine messbare Beschleunigung Ihrer Anwendung dar: Vergleichen Sie Kompilierung, Hydratation und Interaktionen mit Ihrem eigenen Code.

#Geben Sie unabhängige Stile parallel aus

experimentell.parallelBuilds zielt auf eine bestimmte App Router-Build-Phase ab. Nach der geordneten Abhängigkeitserkennung friert PRNext Stylesheet-Pläne ein, dedupliziert Ausgaben und verteilt unabhängige Jobs. Die Verknüpfung bleibt deterministisch, um die Stylesheet-Reihenfolge beizubehalten.

Die Parallelität hängt von der Anzahl der CPU, dem verfügbaren Speicher und den konfigurierten Obergrenzen ab. In diesem Beispiel sind höchstens zwei Arbeitnehmer mit einem geschätzten Eintrittsbudget von 512 MiB zulässig. Das Budget ist kein erzwungenes RSS-Limit für Code von Drittanbietern.

export default {
  experimental: {
    parallelBuilds: {
      maxWorkers: 2,
      maxMemoryMb: 512
    }
  }
};

Benutzerdefinierte Webpack-Hooks, Loader und PostCSS-Pipelines sowie Sass-Rückrufe behalten die serielle Ausführung bei. Wenn ein Job fehlschlägt, stoppt PRNext neue Zulassungen, erledigt bereits begonnene Arbeiten und verwirft den Staging-Build. Der zuletzt veröffentlichte Build bleibt verfügbar. Das Manifest zeichnet die tatsächliche Anzahl der Stylesheet-Jobs und die ausgewählte Parallelität auf und unterscheidet so eine aktivierte Option von tatsächlich durchgeführter paralleler Arbeit.

#Lesen Sie einen Upload, bevor er vollständig eintrifft

Mit experimentell.streamingRequestBodies kann ein Node App Router Route Handler mit dem Lesen von Request.body beginnen, bevor der gesamte Upload eintrifft. Der native Transport verhandelt diese Funktion mit dem Worker und sendet höchstens einen 64 KiB-Frame pro Leserkredit. Der Verbraucher steuert das Liefertempo.

Worker ohne diese Funktion nutzen den vorhandenen gepufferten Pfad. Auch Serveraktionen, Seiten-APIs und bereits von der Middleware gepufferte Anfragen behalten ihr bisheriges Verhalten bei. Das Gesamtanfragelimit beträgt weiterhin 32 MiB und bestehende Zulassungsreservierungen gelten weiterhin. Diese Option verspricht weder eine allgemeine Reduzierung der V8-Heap-Nutzung noch eine erhöhte Parallelität der Speicherzugriffe.

export default {
  experimental: {
    streamingRequestBodies: true
  }
};

Der Handler wird möglicherweise ausgeführt, bevor eine Kürzung oder ein übermäßiger Upload erkannt wird. Überprüfen Sie die vollständige Eingabe und Autorisierung, bevor Sie einen geschäftlichen Effekt erzielen. Durch einen Abbruch oder eine vorzeitige Rückkehr wird die Spur dieses Uploads geschlossen, ohne dass die Mutation erneut abgespielt wird oder der gesunde Node-Host geopfert wird. Analysieren Sie für einen Datenimport schrittweise und schreiben Sie die Transaktion fest, sobald alle Bedingungen erfüllt sind.

#Geben Sie Compiler-Caches ein Budget

Compiler-Caches teilen sich ein 256 MiB-Aufbewahrungsziel pro Projekt, konfigurierbar über CompilationCache.maxDiskSize. Die Richtlinie wird nach Builds, einschließlich fehlgeschlagener Builds, und nach einem ordnungsgemäßen Herunterfahren der Entwicklung ausgeführt. Es schränkt die Aufbewahrung berechtigter Dateien ein; Aktive Mitarbeiter, ausgelastete Dateien oder unvollständige Scans können die Wiederherstellung verzögern.

prnext cache meldet Statistiken für erkannte Dateien. Im Trockenlaufmodus wird eine Vorschau des Beschnitts angezeigt, ohne dass Daten gelöscht werden. In diesem Beispiel werden Caches überprüft und dann ein 64 MiB-Ziel aus einer Anwendung simuliert, die diese Version von PRNext verwendet.

npx --no-install prnext cache --json
npx --no-install prnext cache --prune --dry-run --max-bytes 67108864 --json

Große JSON-Datensätze verwenden eine Komprimierung mit dekodierter Größe, Schlüssel- und Prüfsummenvalidierung. Vorhandene Rohdatensätze bleiben lesbar; Beschädigte oder inkompatible Einträge werden zu Cache-Fehlern. Die Veröffentlichung bleibt atomar und Cache-Fehler werden nicht zu einer zwingenden Abhängigkeit der Kompilierung.

Stoppen Sie die Entwicklung, bevor Sie einen Schnitt anwenden. Ausgenommen sind Laufzeitdatenbanken, data.sqlite3, Seiten- und Bildcaches sowie der Invalidierungsverlauf. Hierbei handelt es sich eher um ein Aufbewahrungsziel als um ein Festplattenkontingent. Die Entfernung kann einen späteren Build verlangsamen oder das erneute Herunterladen einer Schriftart erforderlich machen.

#Behalten Sie weniger Abhängigkeiten und redundante Artefakte bei

PRNext bündelt den Node create()-Eintrag von Fontkit mit Provenance- und Dependency-Lizenzen. TTF, OTF/CFF, WOFF, WOFF2, TTC, DFONT und variable Schriftarten bleiben abgedeckt, ohne dass der vollständige externe Fontkit-Abhängigkeitsbaum für diese Verwendung installiert werden muss. Die interne Integration ersetzt nicht die von Ihrer Anwendung vorgenommenen Fontkit-Importe.

Ein Produktions-Build behält bei Bedarf einen OpenGraph-Renderer bei. Bei der begrenzten Analyse kompilierter Diagramme kann dies nur dann weggelassen werden, wenn ImageResponse als unbenutzt zertifiziert ist. Edge, Entwicklung, unbekannte externe Module und berechnete Auslastung behalten ihr konservatives Verhalten bei. Namen, Lizenzen und relative WASM-Belastung bleiben erhalten.

Durch kleine SQLite-Schritte und die begrenzte Wartung verwaister Dateien wird Laufzeitraum vom Anforderungspfad zurückgewonnen. Aktive Leser und Veröffentlichungen sind geschützt. Vorhandene Datenbanken behalten ihr Format und während einer Anfrage wird kein vollständiger VACUUM ausgeführt. Temporäre Build- und Entwicklungsverzeichnisse verfügen außerdem über Eigentumsprotokolle: Nur lokale Eigentümer, die als verlassen bestätigt wurden, sind für die Wiederherstellung berechtigt, während für die Wiederherstellung erforderliche Backups intakt bleiben.

Stellen Sie bei eigenständigen Bereitstellungen das vollständige Standalone-Verzeichnis bereit, ohne auch den normalen Build daneben zu kopieren. Dadurch wird vermieden, dass die Artefakte, die das Framework gerade zusammengestellt hat, dupliziert werden.

#Entfernen Sie unnötige Durchläufe in Builds und im Browser

App-Chunk-Importe werden vor dem ersten Schreibvorgang neu in den Speicher geschrieben. Die Erkennung übergeordneter Verzeichnisse wird innerhalb eines Builds gemeinsam genutzt, und begrenzte Oxc-Zusammenfassungen verwenden Direktiven- und Exportinformationen wieder, ohne große Syntaxbäume beizubehalten. Transformationen, die Babel brauchen, behalten ihren bisherigen Weg.

Im Browser wird durch die Übernahme einer Gruppe von Stylesheets ein temporärer Index vorhandener Links erstellt, anstatt das Dokument nach jedem Blatt zu durchsuchen. Beim Rust-Routing werden gewöhnlichere Pfade und Segmente übernommen. Flight Capture entfernt eine Zwischenkopie nur für interne Puffer, wenn der Eigentümer dies zulässt, und behält defensive Kopien für externe Produzenten bei.

Flugkomprimierungssonden werden mit begrenzter Parallelität asynchron. Bei Sättigung verwenden die Antworten den normalen Flight. PPR-Preloads verwenden die native Base64-Dekodierung wieder, sofern verfügbar, und behalten den Browser-Fallback bei. Durch diese Änderungen werden identifizierte Vorgänge reduziert; Sie messen die HTTP-Latenz oder die vollständige Build-Dauer nicht unabhängig voneinander.

#Behalten Sie HTTPS und separate Konten im Client-Status bei

Hinter einem Reverse-Proxy kann die Rekonstruktion eines HTTP URL eine Umleitung, ein sicheres Cookie oder einen Authentifizierungsrückruf unterbrechen. server.publicOrigin definiert jetzt den kanonischen externen Ursprung für Anforderungs-URLs und Weiterleitungen. Es hat Vorrang vor Weiterleitungsheadern.

server.trustedProxies begrenzt die IP-Adressen oder CIDR-Netzwerke von Proxys, die eine direkte Verbindung zu PRNext herstellen. Nur ein zugelassener TCP-Peer darf das weitergeleitete Protokoll und den Host bereitstellen. Diese Regel validiert keine vollständige Client-IP-Kette. Ersetzen Sie die Beispieldomäne und -adressen durch die Ihrer Bereitstellung und erstellen Sie dann das Artefakt neu, das diese Einstellungen speichert.

export default {
  server: {
    publicOrigin: 'https://example.com',
    trustedProxies: ['127.0.0.1', '::1']
  },
  navigationCache: {
    authCookies: [
      'session-cookie-name',
      '__Secure-session-cookie-name'
    ]
  }
};

Cookie-Namen müssen mit Ihrer Authentifizierungsbibliothek übereinstimmen, einschließlich ihrer sicheren Varianten. Mit dieser Richtlinie erfordert eine geänderte oder unbekannte Identität ein neues Dokument, bevor beibehaltene Layouts oder Seiten übernommen werden. Eine frisch verifizierte Identität mit demselben Konto kann ihren Entwurf behalten. PPR-Vorschauen warten auf diese Prüfung und vollständig statische Modelle verwenden eine Dokumentanforderung.

Die Grenze schützt auch den Kontowechsel und die Wiederherstellung des Verlaufs. Testen Sie Konto A, melden Sie sich ab und dann Konto B im selben Tab: Die alten Layout-Requisiten und privaten Entwürfe von A dürfen für B nicht angezeigt werden. Die Anwendung bleibt für die Autorisierung aller geschützten Server-Lesevorgänge und -Mutationen verantwortlich.

#Überprüfen Sie eine Instanz, nachdem Sie den Datenverkehr gewechselt haben

Eine 302-Umleitung zu einer Anmeldeseite stellt keinen Anwendungszustand her. Sonden erfordern jetzt vollständige, begrenzte HTTP 200-Antworten. Der reservierte native Endpunkt /_prnext/health bestätigt, dass der Server Datenverkehr akzeptieren kann und nicht mehr verfügbar ist, sobald das ordnungsgemäße Herunterfahren beginnt.

Native Readiness zertifiziert weder einen On-Demand-Node-Worker noch eine Datenbank. Eine dedizierte anonyme, schreibgeschützte Anwendungsroute kann die für die Verarbeitung des Datenverkehrs erforderlichen Abhängigkeiten überprüfen. Konfigurieren Sie es als Integritätspfad für eine dauerhafte Anwendung. Zuvor gespeicherte Integritätspfade bleiben unverändert: Ein alter /-Pfad, der umleitet, muss explizit durch diese dedizierte Route ersetzt werden.

Nach einem erfolgreichen Datenverkehrswechsel behält der Manager die vorherige Instanz während eines Überwachungsfensters bei, standardmäßig 15 Sekunden. Drei aufeinanderfolgende Integritätsfehler oder ein unerwarteter Ersatzexit können eine Rückkehr zur vorherigen Instanz auslösen, wenn diese noch fehlerfrei ist. Bereits gestartete Antworten werden abgezogen, es wird jedoch keine Anfrage oder Mutation wiederholt. Ein Code-Rollback macht einen SQL-Schreibvorgang oder eine Schemamigration nicht rückgängig.

#Verstehen Sie bereits begangene Fehler und Auswirkungen

Die SaaS-Referenz demonstriert die kontobezogene Transaktionsidempotenz. Wenn ein Schreibvorgang erfolgreich ist, die Antwort jedoch verloren geht, führt ein expliziter Wiederholungsversuch mit demselben Schlüssel nur zu einem Schreibvorgang. Die Einschränkung und die Transaktion gehören zur Anwendung. Das Framework kann nicht darauf schließen, dass eine andere Übermittlung sicher ist.

Qualifizierungsszenarien umfassen PostgreSQL-Ausfälle und -Wiederherstellung, gleichzeitige Ansprüche desselben Schlüssels, Antwortverlust nach COMMIT, SQLite-Sperre und SQLITE_FULL für eine verfügbare Datenbank sowie einen echten Redis-Absturz und -Neustart. Sie ergänzen erfolgreiche nominelle Arbeitsabläufe mit Situationen, in denen das Geschäftsergebnis verständlich bleiben muss.

HTTP-Metriken sind optional und durch PRNEXT_METRICS_TOKEN trägergeschützt. Sie stellen Dauer, aktive Anfragen, Ergebnisse, Zugangssättigung und Arbeitsereignisse mit begrenzten Bezeichnungen bereit. Schaben Sie weiterhin privat. OTLP-Exportverluste, Warteschlangenüberläufe und teilweise Zurückweisungen verfügen über Zähler; Die Knotendiagnose nutzt auch den prnext.telemetry-Kanal, um beobachtbar zu bleiben, wenn der Trace-Kollektor nicht verfügbar ist.

Die Abhängigkeitsüberwachung prüft täglich npm, Cargo und eingebettete Renderer- und Schriftartkomponenten sowie wöchentliche Aktualisierungen und aufgezeichnete Herkunft. Ein Release-Time-Audit bleibt eine Momentaufnahme und kein Ersatz für die Überwachung neuer Sicherheitshinweise.

#Was die Messungen belegen

Die Speicherstudie ist älter als der endgültige Kandidat und verwendet Windows x64, Knoten 24.22.1, passende React 19.3.1-Peers und dieselbe öffentliche native ausführbare Datei. Die neu installierte Größe sinkt von 159.05 auf 141.98 MiB mit 13 weniger Paketen. Diese Zahlen messen nicht die endgültigen 0.1.20-alpha-Archive und werden nicht automatisch auf eine andere Plattform übertragen.

Über 28-Builds von zwei kleinen synthetischen SSR-Korpora hinweg reduzieren gepaarte warme Mediane die logischen Build-Bytes um 67.79% ohne OpenGraph und 26.61% mit OpenGraph. Die Anzahl der Compiler-Cache-Bytes sinkt um etwa 64.4%. Beobachtete Build-API-Wandzeit erhöht sich um 13.94 und 15.85 ms. Hierbei handelt es sich eher um logische Dateien als um zugewiesene Festplattenblöcke und um einen Speicherkompromiss und nicht um eine allgemeine Geschwindigkeitsverbesserung.

Die in den technischen Hinweisen genannte SaaS-Kampagne läuft zwei Stunden lang auf der Qualifikationsquelle 2323dc55 unter den beobachteten Grenzwerten von zwei CPUs und 5 GiB. Es führt 9,238 SQL-Schreibvorgänge und 11 Worker-Rotationen mit 235 verifizierten Prozess- und Dateideskriptorbeispielen durch. Elf schreibgeschützte Sonden versagen während der induzierten Rotationen und bleiben aufgezeichnet; Es wird keine Mutation wiederholt. Diese Beobachtungen behalten ihre ausgeführte Quelle bei und werden nicht als Test für die endgültigen Archive präsentiert.

Diese Ergebnisse dokumentieren Mechanismen und kontrollierte Arbeitsbelastungen. Sie stellen weder einen allgemeinen HTTP-Latenzgewinn noch eine allgemeine Speicherreduzierung, das Fehlen von Lecks oder ein Produktions-SLA fest. Die mit diesem Artikel verknüpften technischen Hinweise enthalten die Bedingungen und Einschränkungen der Kampagnen.

#Bereiten Sie eine Bereitstellung mit Ihrer eigentlichen Anwendung vor

Wenn passende Pakete installiert sind, untersucht prnext check --production --json Bereitstellungseinstellungen, Artefaktdrift, Beibehaltung des authentifizierten Zustands und experimentelle Optionen. Es bietet eine Diagnose, bevor der Datenverkehr umgeschaltet wird. Es kann die für Ihr Produkt spezifischen Routen, Formulare und Rückrufe nicht ersetzen.

npm install @thomas.f/prnext@0.1.20-alpha react@19.3.1 react-dom@19.3.1 react-server-dom-webpack@19.3.1
npx --no-install prnext check --production --json
npx --no-install prnext typecheck
npx --no-install prnext build
npx --no-install prnext output --json

PRNext 0.1.20-alpha erfordert Knoten ^22.23.4, ^24.22.1 oder >=26.12.1 mit React, React DOM und React-Server-Dom-Webpack ausgerichtet auf 19.3.1.. Halten Sie optionale native Abhängigkeiten aktiviert und Framework- und native Paketversionen identisch. Für die explizite Typprüfung sind die TypeScript-Installation und die tsconfig der Anwendung erforderlich. Diese Anforderungen ersetzen nicht die Anwendung neuer Sicherheitspatches für jede Abhängigkeit.

Nachdem Sie die Version geändert haben, erstellen Sie die Anwendung neu und starten Sie sie neu. Stoppen Sie für pstart zunächst den Supervisor mit pdown unter Verwendung desselben PRNEXT_PM_HOME, aktualisieren und erstellen Sie dann jede aktivierte Anwendung, die diesen Supervisor gemeinsam nutzt, neu, bevor Sie sie neu starten. Prestart allein lädt den Supervisor-Code nicht neu. Behalten Sie die vorherige Bereitstellung und kompatible Datenbankmigrationen bei, um eine Rückkehr zu ermöglichen.

PRNext bleibt ein Alpha mit teilweiser Next.js-Kompatibilität. Aktivieren Sie experimentelle Pfade separat und testen Sie einen repräsentativen Workflow: Kaltladen, Stile, Navigation, Kontowechsel, unterbrochene Uploads und ein Abhängigkeitsausfall. Im zugehörigen Upgrade-Leitfaden werden diese Prüfungen und die Grenzen der einzelnen Optionen detailliert beschrieben.