PRNext 0.1.19: Bei der ersten Verwendung kompilieren, Status beibehalten

Ein Editor, der auf einer Seite verwendet wird, sollte nicht bei jedem Start seine Kompilierungsarbeit hinzufügen. Ein in Bearbeitung befindliches Formular sollte nicht verschwinden, weil während des Absendens eine Codeänderung eintrifft. PRNext 0.1.19-alpha behebt diese Situationen durch eine verzögerte Clientkompilierung, gezieltere Entwicklungsaktualisierungen und eine bessere Koordination zwischen Serveraktionen und schneller Aktualisierung.

Diese Version bietet Ihnen außerdem mehr Kontext vor einer Migration und ein vollständiges Beispiel für die Ausführung einer Anwendung mit Konten, einer Datenbank und Authentifizierung. Hier erfahren Sie, was sich in Ihrem Projekt ändert, wie Sie die nützlichen Optionen aktivieren und wo ihre Grenzen wichtig sind.

Halten Sie die Arbeit durch eine Codebearbeitung am Laufen

Stellen Sie sich ein Dashboard mit einem Filter im Layout und einem Formular vor, das eine Serveraktion aufruft. Sie speichern eine Komponente, während die Formularantwort eintrifft. PRNext koordiniert diese Vorgänge, um das bereitgestellte Layout beizubehalten, wenn das Update kompatibel ist, anstatt aktualisierte Aktionsverweise als Grund zum erneuten Starten der Seite zu betrachten.

Aktionen, deren Quelle unverändert bleibt, behalten ihre Identität innerhalb der Entwicklungssitzung, auch mit Cache-Komponenten. Veränderte Handlungen erhalten neue Identitäten. Produktions-Builds behalten unabhängige Identitäten. Eine alte Flight-Antwort kann ein Rendering einer neueren Generation nicht überschreiben und ein Aktionsfehler bleibt auch dann beobachtbar, wenn die Navigation das Rendering ersetzt.

Die Mutation und ihre Anzeige bleiben getrennte Vorgänge. Eine neuere Interaktion kann eine ältere Anzeige irrelevant machen, aber PRNext übermittelt die Mutation nie erneut. Inkompatible Bearbeitungen, einige Konfigurationsänderungen und ein vollständiges Neuladen des Dokuments können immer noch den im Speicher gehaltenen Status zurücksetzen.

Kompilieren Sie ein großes Tool, wenn Sie es öffnen

Ein gewöhnlicher dynamischer Import erzeugt während der Kompilierung einen Block, auch wenn er beim Herunterladen auf eine Interaktion wartet. In der Entwicklung geht „experimental.lazyDynamicImports“ noch einen Schritt weiter: Es hält geeignete Client-Ziele außerhalb des anfänglichen Browserdiagramms und wartet auf ihre erste Verwendung, bevor es sie transformiert und kompiliert.

Aktivieren Sie diese Option in einer App Router-Anwendung mit dem nativen Compiler. Ein Editor, ein Viewer oder ein selten geöffnetes Panel ist ein nützlicher Ort, um das Verhalten zu vergleichen. Die Option ist standardmäßig deaktiviert.

prnext.config.mjs
export default {
  experimental: {
    lazyDynamicImports: true
  }
};

Bei der ersten Nutzung werden die Kosten für die Erstellung dieses Untergraphen übernommen. Dateien werden im Private Staging aufbereitet und vollständig veröffentlicht. Stile werden geladen, bevor der Import aufgelöst wird. Nach der Aktivierung nimmt das Modul an JavaScript- und CSS-Updates teil. Bereits geladene ESM-Abhängigkeiten behalten ihre Identität und Live-Bindungen; Zwei Importer nutzen außerdem dasselbe JSON-Objekt.

Der beabsichtigte Vorteil besteht darin, dass die Arbeit aus dem Startup verschoben wird, wenn Ihr Workflow dieses Tool nicht verwendet. Messen Sie den Anlauf und die Verzögerung bei der ersten Verwendung gemeinsam. Die Option ändert weder Produktionsblöcke noch das Server-Rendering-Verhalten.

Ein Beispiel mit einem Nur-Browser-Editor

Eine nächste/dynamische Komponente mit ssr: false hält den Editor im Browser. In diesem Beispiel wird die Komponente erst angefordert, nachdem das Panel geöffnet wurde. Wenn die verzögerte Kompilierung aktiviert ist, wartet der berechtigte Clientcode auf diese Verwendung.

app/editor-panel.jsx
'use client';

import { useState } from 'react';
import dynamic from 'next/dynamic';

const Editor = dynamic(() => import('./editor'), {
  ssr: false,
  loading: () => <p>Loading the editor…</p>
});

export default function EditorPanel() {
  const [open, setOpen] = useState(false);
  return open
    ? <Editor />
    : <button onClick={() => setOpen(true)}>Open the editor</button>;
}

Der anfängliche Umfang schließt Webpack-Hooks und benutzerdefinierte Loader aus. Berechnete Importe, Importattribute und Literalpfade, die ? oder # normale Kompilierung beibehalten. Ein Suffix, das durch einen Alias ​​oder eine Abhängigkeit innerhalb eines verzögerten Diagramms eingeführt wird, führt zu einem expliziten Fehler. Eine gemeinsame CommonJS-Abhängigkeit, deren Identität nicht beibehalten werden kann, und eine neue Serveraktion, die nur über dieses Diagramm erkannt wird, erfordern ebenfalls den normalen Pfad oder einen geeigneten statischen Import.

Aktivierte Stile bleiben für die Entwicklungsgenerierung geladen, auch bei parallelen Routen. Bevorzugen Sie CSS-Module oder lokale Selektoren für das Tool. Der Mechanismus erfordert Hardlinks auf dem Dateisystem der Generation; Deaktivieren Sie die Option, wenn diese Umgebung sie nicht erstellen kann.

Bearbeiten Sie ein Stylesheet, ohne den Build JavaScript zu kopieren

Eine kompatible CSS-Bearbeitung erstellt die betroffenen Bundles neu und veröffentlicht eine kleine Stilgeneration über der aktuellen JavaScript-Generation. PRNext behält noch verwendete Ressourcen, einschließlich Bilder, Schriftarten und Quellkarten, ohne jede JavaScript-Datei für dieses Update zu scannen oder zu kopieren.

Wenn Sie die Stile eines Panels bearbeiten und dann ein anderes Panel mehrmals bearbeiten, bleiben die geänderten Ressourcen des ersten Panels im begrenzten Stilkatalog verfügbar. Unveränderte Ressourcen bleiben in der Basisgeneration zugänglich. Eine unvollständige Provenienz, ein übergroßer Katalog oder eine inkompatible Änderung führen zu einem vollständigen Build.

Inkrementelle Diagramme teilen ihr Budget auch zwischen Hauptkompilierung und Stilen auf. Wenn ein Projekt über viele CSS-Bereiche verfügt, können Stile ungenutzte Kapazität ausleihen, ohne dass Hauptdiagramme ständig entfernt werden müssen. Die Beschränkungen bleiben global und die Arbeit wird verworfen, wenn die Sitzung geschlossen wird.

Auf macOS kann eine Verzeichnisbenachrichtigung mehrere Änderungen kombinieren. PRNext überprüft die Dateien in diesem Quellunterbaum, um eine tiefgreifende Bearbeitung zu erkennen, sowohl in der Entwicklung als auch mit build --watch. Bleibt die Überprüfung unvollständig, wird ein behebbarer Fehler gemeldet und der vorherige Build beibehalten, ohne eine Kompilierungsschleife zu starten.

Machen Sie sich mit einer Inkompatibilität vertraut, bevor Sie Laufzeiten ändern

Ein unterstützter next/*-Import in Ihrer Quelle kann eine Abhängigkeit verbergen, die einen anderen privaten API verwendet. Das Migrationsaudit verfolgt erreichbare statische Importe in installierte Pakete. Es berücksichtigt Browser-, Knoten- und React-Serverkomponentenkontexte und meldet die Datei-, Zeilen- und Importkette hinter einer Diagnose.

Eine Nutzungsservergrenze bleibt eine Servergrenze, wenn eine Clientkomponente sie durch einen erneuten Export erreicht. Eine Browserabhängigkeit von einem Knoten API wird anhand von Browserzuordnungen und installierten Implementierungen überprüft und nicht akzeptiert, nur weil das Paket vorhanden ist.

Beginnen Sie bei einem Projekt, bei dem die beabsichtigte PRNext-Version bereits installiert ist, mit Prüfungen, die keine Migration anwenden:

Terminal
npx --no-install prnext migrate --dry-run
npx --no-install prnext migrate --check --json

Der Bericht unterscheidet überprüftes Verhalten von unbekanntem Verhalten. Ein berechneter Import, eine Loader-Ausgabe oder ein Traversal-Limit wird nicht zu einem impliziten Erfolg. Bei der Prüfung werden die von ihr überprüften Abhängigkeitsmodule nicht ausgeführt, bei der Auswertung der Konfiguration kann jedoch Projektcode ausgeführt werden. Es handelt sich weder um eine Sandbox für nicht vertrauenswürdigen Code noch um ein Kompatibilitätszertifikat. Ein echter Build und Ihre Anwendungsworkflows sind weiterhin erforderlich.

Gehen Sie über eine Demoseite hinaus zu einer Anwendung mit Konten

Das Saas-Referenzbeispiel kombiniert Better Auth, PostgreSQL, Drizzle und next-intl in einer französischen und englischen Anwendung. Jedes Konto besitzt seine Notizen. Das Dashboard überprüft die Sitzung und bei jeder Mutation werden Benutzer und Dateneigentum erneut überprüft. Es reicht nicht aus, eine Schaltfläche auszublenden oder nur die Seite zu schützen.

Authentifizierungsformulare wenden gemeinsame, atomare PostgreSQL-Budgets vor teurem Passwort-Hashing an. Qualifizierungsworkflows üben Sitzungssperrungen, CSRF-Ablehnungen und ungültige OpenID Connect-Rückrufe aus und verwenden dazu einen kontrollierten lokalen Anbieter und einen HTTPS-Proxy, der sichere Cookies überprüft.

Dieselbe Anwendung wird nach der Verlagerung ihrer eigenständigen Ausgabe getestet, wobei zwei Worker und die ursprüngliche Quelle entfernt werden. Es handelt sich um einen überprüfbaren Ausgangspunkt. Zugriffsregeln, Kontowiederherstellung, Verifizierung und Missbrauchsbeschränkungen müssen weiterhin zu Ihrem Produkt passen. Halten Sie bei der Bereitstellung das Backend hinter einem vertrauenswürdigen Proxy privat, der Weiterleitungsheader überschreibt.

Übernehmen Sie die Freigabe mit den richtigen Prüfungen

Überprüfen Sie nach einem Update die tatsächlich installierte Version und die ausgerichteten React-Abhängigkeiten, erstellen Sie dann die Anwendung neu und starten Sie sie neu. Wenn Sie von Next.js migrieren, bewahren Sie den Prüfbericht auf und verwenden Sie authentifizierte Routen, Formulare, Stile und Navigation. Vergleichen Sie eine experimentelle Option in Ihrem eigenen Projekt, bevor Sie sie aktiviert lassen.

PRNext bleibt ein Alpha mit teilweiser Next.js-Kompatibilität. Die funktionale Qualifikation umfasst Linux, macOS und Windows sowie Chromium, Firefox und WebKit. Diese Prüfungen belegen keinen allgemeinen Leistungsgewinn. Eine historische Kampagne bleibt ergebnislos, weil Prozessbeobachtungen unvollständig sind; Die Leistung dieser Version wird dadurch nicht bestimmt. Frühere Windows-EPERM-Fehler während der Veröffentlichung des atomaren Entwicklungsstatus sind weiterhin dokumentiert, ohne nachgewiesene Ursache oder spezifische Lösung.

Ein repräsentativer Arbeitsablauf ist ein nützlicher Ausgangspunkt: Öffnen Sie eine kalte Route, bearbeiten Sie ihre Stile, senden Sie ein Formular und kehren Sie zu einer zuvor besuchten Seite zurück. Dadurch wird überprüft, welche Änderungen sich in der Version für Ihre Anwendung ergeben, einschließlich ihrer Abhängigkeiten, Authentifizierungs- und Bereitstellungseinschränkungen.

Quellen und weiterführende Literatur

Zurück zum Blog