PRNext 0.1.20: 作業量を減らし、より多くの制御を実現
PRNext 0.1.20-alpha が利用可能です。このバージョンでは、アプリケーションの使用に伴って増大する 2 つのコスト、つまり不必要に実行される作業と運用動作の理解の難しさに対処します。パブリック ページはネイティブ シェルで開始でき、サーバー アクションの編集では無関係なタブを省略でき、コンパイラ キャッシュには共有の保持予算があります。
このリリースでは、明示的な HTTPS オリジン、リダイレクトを拒否するヘルスチェック、トラフィック切り替え後のロールバック、および保護されたメトリクスによる展開制御も強化されています。新しい実験的パスはデフォルトでは無効のままです。それぞれが、定義されたアクティブ化条件、フォールバック、または明示的なエラーを伴う特定のユースケースに対応します。
ノードが初期化される前に PPR ページを開始します
PPR ページは、ビルド中に準備された部分と、動的コンテンツを生成する React 継続とを組み合わせます。 Experimental.nativePprShell を使用すると、Rust サーバーはノード ワーカーを開始する前に認定シェルを送信できます。その後、独立した初期応答を構築するのではなく、同じチェックされたアーティファクトから継続が再開されます。
このパスは、Cookie、承認、またはクエリ文字列を使用しない具体的な App Router PPR ドキュメントの GET をカバーします。これにはcacheComponentsが必要です。ミドルウェア、リライト、basePath、CSP nonce、または Flight ナビゲーション ヘッダーを含むリクエストは、通常のレンダリングを保持します。汎用パラメーター シェル、エッジ、および外部キャッシュもこの範囲外のままです。
export default {
cacheComponents: true,
experimental: {
nativePprShell: true
}
};シェルは無傷で有効期限が切れていない必要があります。無効化が永続化されると、PPR を無効にすることなく、再起動時も含めてこのビルド スナップショットの最適化が無効になります。すでにスナップショットを使用しているリクエストは、同じアーティファクトで終了します。応答は非公開のままで、保存されません。このメカニズムは、認証されたページをパブリック コンテンツに変換したり、承認を置き換えたりすることはありません。
サーバーアクションの影響を受けるルートを更新する
請求画面で使用されるアクションを編集する場合、製品の無関係な部分で開いているタブを中断する必要はありません。 PRNext は、編集の前後で依存関係グラフを比較し、アクションを直接インポートするルート、またはその依存関係を通じてアクションをインポートするルートを特定します。
その範囲が確立されると、影響を受けるルートを開発リフレッシュの対象にすることができます。予備のタブは、変更されたルートに移動する前に、遅延生成を適用します。サーバーの世代は引き続き全体として公開され、保留中の変更が更新に伴って再度送信されることはありません。
不明なグラフまたは不完全なグラフは、グローバル更新を保持します。構成、ルート、ランタイム、バインディングの変更も、ミドルウェア、書き換え、および特定の国際化された並列ルートまたはインターセプト ルートに加えて行われます。ターゲティングは、保存したばかりのファイルに関する仮定ではなく、確立されたスコープに依存します。
すべてのプロジェクトに React コンパイラをインストールせずに、React コンパイラとして Oxc を選択します
React コンパイラは、既存の Babel バックエンドに加えて実験的な Oxc バックエンドを取得します。ブラウザ出力とアプリ クライアント コンポーネント サーバーのレンダリングでは、別個の変換が使用されます。キャッシュ ID にはバックエンド、コンパイラーのバージョン、クライアントまたは SSR モードが含まれるため、結果が間違ったコンテキストで再利用されることはありません。
ReactCompiler が有効になっている場合、Babel はデフォルトのままです。 Oxc を選択するには、オプションのネイティブ依存関係を有効にしてアプリケーション プロジェクトに oxc-transform-react@0.157.0 を明示的にインストールします。グローバル CLI であっても、アプリケーションからこのコンパイラーを解決します。コンパイラまたはネイティブ バインディングが見つからないか、互換性がない場合は、明示的なエラーが生成されます。 PRNext はバックエンドをサイレントに変更することはありません。
export default {
reactCompiler: {
backend: 'oxc'
}
};スコープは引き続き適格なプロジェクト コンポーネントとフックです。サーバー コンポーネント、サーバー アクション、npm パッケージ、およびページ サーバー グラフは、この変換の範囲外にあります。ソース マップと高速リフレッシュは保持されます。 prnext コンパイラ レポートは、バックエンドおよびファイル レベルの診断を特定します。 Oxc API は、Babel のように、最適化された関数をカウントするために必要なイベントを提供しません。
Babel を保持するプロジェクト、または React コンパイラーを無効にするプロジェクトは、PRNext の内部使用のために Oxc をインストールしなくなりました。 Rust で書かれたコンパイラを選択しても、アプリケーションの速度向上は測定されません。コンパイル、ハイドレーション、および対話を独自のコードと比較してください。
独立したスタイルを並行して出力する
Experimental.ParallelBuilds は、特定の App Router ビルド ステージをターゲットとしています。順序付けされた依存関係の検出後、PRNext はスタイルシート プランを凍結し、出力の重複を排除し、独立したジョブを分散します。スタイルシートの順序を維持するために、リンクは決定的なままです。
同時実行性は、CPU 数、利用可能なメモリ、および設定された上限によって異なります。この例では、推定入場予算 512 MiB を持つワーカーを最大 2 人まで許可します。この予算は、サードパーティ コードに対する強制的な RSS 制限ではありません。
export default {
experimental: {
parallelBuilds: {
maxWorkers: 2,
maxMemoryMb: 512
}
}
};カスタム Webpack フック、ローダー、PostCSS パイプライン、および Sass コールバックはシリアル実行を保持します。ジョブが失敗した場合、PRNext は新しい受付を停止し、すでに開始された作業を解決し、ステージング ビルドを破棄します。最後に公開されたビルドは引き続き利用可能です。マニフェストには、実際のスタイルシート ジョブ数と選択された同時実行性が記録され、有効なオプションと実際に実行された並列作業が区別されます。
アップロードが完了する前にアップロードを読む
Experimental.streamingRequestBodies を使用すると、ノード アプリ ルーターのルート ハンドラーは、アップロード全体が到着する前に Request.body の読み取りを開始できます。ネイティブ トランスポートは、この機能をワーカーとネゴシエートし、リーダー クレジットごとに最大 1 つの 64 KiB フレームを送信します。消費者が配送ペースをコントロールします。
その機能を持たないワーカーは、既存のバッファされたパスを使用します。サーバー アクション、ページ API、およびミドルウェアによって既にバッファリングされているリクエストも、以前の動作を保持します。合計リクエスト制限は 32 MiB のままで、既存の入場予約は引き続き適用されます。このオプションは、V8 ヒープ使用量の全体的な削減やメモリ アドミッションの同時実行性の向上を約束するものではありません。
export default {
experimental: {
streamingRequestBodies: true
}
};ハンドラーは、切り捨てまたは過剰なアップロードが検出される前に実行される場合があります。ビジネス効果をコミットする前に、完全な入力と承認を検証します。キャンセルまたは早期の復帰により、ミューテーションを再実行したり、正常なノード ホストを犠牲にしたりすることなく、アップロードのレーンが閉じられます。データのインポートの場合は、段階的に解析し、すべての条件が満たされた時点でトランザクションをコミットします。
コンパイラのキャッシュに予算を与える
コンパイラ キャッシュは、プロジェクトごとに 256 MiB 保持目標を共有します。これは、compilationCache.maxDiskSize を通じて構成できます。このポリシーは、失敗したビルドを含むビルド後、およびクリーンな開発のシャットダウン後に実行されます。対象となるファイルの保持を制限します。アクティブなワーカー、ビジー状態のファイル、または不完全なスキャンにより、再利用が延期される可能性があります。
prnext cache は、認識されたファイルの統計を報告します。そのドライラン モードでは、データを削除せずにプルーニングをプレビューします。この例では、キャッシュを検査し、このバージョンの PRNext を使用してアプリケーションから 64 MiB ターゲットをシミュレートします。
npx --no-install prnext cache --json
npx --no-install prnext cache --prune --dry-run --max-bytes 67108864 --json大きな JSON レコードは、デコードされたサイズ、キー、およびチェックサムの検証を伴う圧縮を使用します。既存の生のレコードは引き続き読み取り可能です。破損したエントリや互換性のないエントリはキャッシュミスになります。パブリケーションはアトミックなままであり、キャッシュの失敗はコンパイルの必須の依存関係にはなりません。
プルーンを適用する前に開発を停止してください。ランタイム データベース、data.sqlite3、ページ キャッシュ、画像キャッシュ、無効化履歴は除外されます。これは、ハードディスク クォータではなく、保持目標です。エビクションにより、その後のビルドが遅くなったり、フォントの再ダウンロードが必要になったりする可能性があります。
依存関係と冗長な成果物を少なくする
PRNext は、Fontkit の Node create() エントリと来歴および依存関係のライセンスをバンドルします。 TTF、OTF/CFF、WOFF、WOFF2、TTC、DFONT、および可変フォントは、この用途のための完全な外部フォントキット依存関係ツリーをインストールしなくても、引き続きカバーされます。内部統合は、アプリケーションによって作成された Fontkit インポートを置き換えるものではありません。
実稼働ビルドでは、必要に応じて 1 つの OpenGraph レンダラーが保持されます。有界コンパイル済みグラフ分析では、ImageResponse が未使用であることが証明されている場合にのみ省略できます。エッジ、開発、未知の外部モジュール、および計算された読み込みでは、保守的な動作が維持されます。名前、ライセンス、および相対的な WASM ロードは保持されたままになります。
ランタイム領域は、小さな SQLite ステップと制限された孤立ファイルのメンテナンスを通じて、リクエスト パスから解放されます。アクティブな読者と出版物は保護されます。既存のデータベースはその形式を維持し、リクエスト中に完全な VACUUM が実行されることはありません。ビルドおよび開発の一時ディレクトリにも所有権ジャーナルがあります。放棄されたことが確認されたローカル所有者のみが再利用の対象となり、回復に必要なバックアップはそのまま残ります。
スタンドアロン展開の場合は、その横に通常のビルドをコピーせずに、完全なスタンドアロン ディレクトリを展開します。これにより、フレームワークが組み立てたばかりの成果物の重複が回避されます。
ビルドとブラウザーで不要なパスを削除する
アプリのチャンクのインポートは、最初の書き込みの前にメモリ内で再書き込みされます。親ディレクトリの検出はビルド内で共有され、制限された Oxc サマリーはディレクティブを再利用し、大きな構文ツリーを保持することなく情報をエクスポートします。 Babel を必要とする変換は、既存のパスを維持します。
ブラウザでは、スタイルシートのグループを採用すると、シートごとにドキュメントをスキャンする代わりに、既存のリンクの一時的なインデックスが構築されます。 Rust ルーティングは、より一般的なパスとセグメントを借用します。フライト キャプチャでは、所有権が許可されている内部所有バッファの中間コピーのみが削除され、外部プロデューサー用の防御コピーが保持されます。
飛行圧縮プローブは、制限された同時実行性により非同期になります。飽和状態では、応答は通常のフライトを使用します。 PPR プリロードは、可能な場合はネイティブの Base64 デコードを再利用し、ブラウザーのフォールバックを保持します。これらの変更により、特定された操作が削減されます。 HTTP レイテンシーや完全なビルド時間を個別に測定することはありません。
HTTPS を保持し、クライアント状態でアカウントを分離します
リバース プロキシの背後で HTTP URL を再構築すると、リダイレクト、安全な Cookie、または認証コールバックが破損する可能性があります。 server.publicOrigin は、リクエスト URL とリダイレクトの正規の外部オリジンを定義するようになりました。これは転送ヘッダーよりも優先されます。
server.trustedProxies は、PRNext に直接接続するプロキシの IP アドレスまたは CIDR ネットワークを制限します。許可された TCP ピアのみが、転送されたプロトコルとホストを提供できます。このルールは、完全なクライアント IP チェーンを検証するものではありません。サンプルのドメインとアドレスをデプロイメントのものに置き換えてから、これらの設定を保存するアーティファクトを再構築します。
export default {
server: {
publicOrigin: 'https://example.com',
trustedProxies: ['127.0.0.1', '::1']
},
navigationCache: {
authCookies: [
'session-cookie-name',
'__Secure-session-cookie-name'
]
}
};Cookie 名は、安全なバリアントを含む認証ライブラリと一致する必要があります。このポリシーでは、変更された ID または不明な ID には、保持されたレイアウトまたはページが採用される前に新しい文書が必要になります。新たに検証された同じアカウント ID は、下書きを保持できます。 PPR プレビューはそのチェックを待ち、完全に静的なモデルはドキュメント リクエストを使用します。
この境界は、アカウントの切り替えと履歴の復元も保護します。アカウント A をテストし、サインアウトして、同じタブでアカウント B をテストします。A の古いレイアウト プロパティとプライベート ドラフトが B に表示されてはなりません。アプリケーションは、保護されたサーバーのすべての読み取りと変更を許可する責任を引き続き負います。
トラフィックを切り替えた後にインスタンスを確認する
サインイン ページへの 302 リダイレクトでは、アプリケーションの正常性は確立されません。プローブには、完全で制限された HTTP 200 応答が必要になりました。予約済みのネイティブ /_prnext/health エンドポイントは、サーバーがトラフィックを受け入れることができることを確認し、正常なシャットダウンが開始されるとすぐに使用できなくなります。
ネイティブ対応性は、オンデマンド ノード ワーカーもデータベースも保証しません。専用の匿名の読み取り専用アプリケーション ルートにより、トラフィックの処理に必要な依存関係をチェックできます。永続アプリケーションのヘルスパスとして構成します。以前に保存されたヘルス パスは変更されません。リダイレクトする古い / パスは、その専用ルートで明示的に置き換える必要があります。
トラフィックの切り替えが成功した後、マネージャーは監視ウィンドウの間 (デフォルトでは 15 秒)、前のインスタンスを保持します。 3 回連続して正常性が失敗するか、予期しない代替終了が発生すると、以前のインスタンスがまだ正常であれば、そのインスタンスへの復帰がトリガーされる可能性があります。すでに開始されている応答は排出されますが、要求や変更は再実行されません。コードのロールバックでは、SQL 書き込みやスキーマの移行は元に戻されません。
すでにコミットされている失敗と影響を理解する
SaaS リファレンスは、アカウントを対象としたトランザクション冪等性を示しています。書き込みは成功したが、その応答が失われた場合、同じキーを使用して明示的に再試行すると、書き込みは 1 回だけ行われます。制約とトランザクションはアプリケーションに属します。フレームワークは、別の送信が安全であると推論できません。
認定シナリオでは、PostgreSQL の停止とリカバリ、同じキーの同時要求、COMMIT 後の応答損失、使い捨てデータベースでの SQLite のロックと SQLITE_FULL、実際の Redis のクラッシュと再起動が実行されます。これらは、ビジネスの結果を理解できる状態にしておく必要がある状況で、成功した名目上のワークフローを補完します。
HTTP メトリックはオプションであり、PRNEXT_METRICS_TOKEN によってベアラーで保護されています。これらは、期間、アクティブなリクエスト、結果、受付の飽和、ワーカー イベントを境界ラベルで公開します。非公開でスクレイピングを続けてください。 OTLP エクスポートの損失、キューのオーバーフロー、および部分的な拒否にはカウンターがあります。ノード診断では、トレース コレクターが利用できない場合でも監視可能な状態を維持するために、prnext.telemetry チャネルも使用されます。
依存関係の監視では、npm、Cargo、埋め込みレンダラーとフォント コンポーネントを毎日チェックし、毎週の更新と記録された出所もチェックします。リリース時の監査は、新しいセキュリティ勧告の監視に代わるものではなく、スナップショットのままです。
測定によって得られるもの
ストレージの検討は最終候補よりも前のもので、Windows x64、React 19.3.1 ピアと一致するノード 24.22.1,、および同じパブリック ネイティブ実行可能ファイルを使用します。新しくインストールされるサイズは 159.05 から 141.98 MiB に減少し、パッケージは 13 少なくなります。これらの数値は、最終的な 0.1.20-alpha アーカイブを測定したものではなく、別のプラットフォームに自動的に転送されるものでもありません。
2 つの小さな合成 SSR コーパスの 28 ビルド全体で、ペアのウォーム メディアンにより、OpenGraph を使用しない場合は 67.79%、OpenGraph を使用する場合は 26.61% だけ論理ビルド バイトが削減されます。コンパイラ キャッシュのバイト数は約 64.4% 減少します。観察されたビルド API のウォールタイムは 13.94 および 15.85 ms 増加します。これらは、割り当てられたディスク ブロックではなく論理ファイルであり、一般的な速度の向上ではなくストレージのトレードオフです。
テクニカル ノートで参照されている SaaS キャンペーンは、2 つの CPU と 5 GiB という観察された制限の下で、認定ソース 2323dc55 で 2 時間実行されます。 235 検証済みのプロセスとファイル記述子のサンプルを使用して、9,238 SQL 書き込みと 11 ワーカー ローテーションを実行します。 11 個の読み取り専用プローブが誘導回転中に失敗し、記録されたままになります。突然変異は再現されません。これらの観察結果は実行されたソースを保持しており、最終アーカイブのテストとしては表示されません。
これらの結果は、メカニズムと制御されたワークロードを文書化します。これらは、一般的な HTTP レイテンシの向上、一般的なメモリの削減、リークの欠如、実稼働 SLA のいずれも確立しません。この記事にリンクされているテクニカル ノートには、キャンペーンの条件と制限が記載されています。
実際のアプリケーションを使用してデプロイメントを準備する
一致するパッケージがインストールされている場合、prnext check --production --json は、デプロイ設定、アーティファクト ドリフト、認証された状態の保持、および実験的なオプションを調べます。トラフィックを切り替える前に診断を提供します。製品固有のルート、フォーム、コールバックを置き換えることはできません。
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 --jsonPRNext 0.1.20-alpha には、ノード ^22.23.4, ^24.22.1 または >=26.12.1 が必要です。React、React DOM、および 19.3.1. で調整された React-server-dom-webpack を必要とします。 オプションのネイティブ依存関係を有効にし、フレームワークとネイティブ パッケージのバージョンを同一に保ちます。明示的な型チェックには、アプリケーションの TypeScript インストールと tsconfig が必要です。これらの要件は、依存関係ごとに新しいセキュリティ パッチを適用することに代わるものではありません。
バージョンを変更した後、アプリケーションを再構築して再起動します。 pstart の場合は、まず同じ PRNEXT_PM_HOME を使用して pdown でスーパーバイザを停止し、次にそのスーパーバイザを共有する有効なアプリケーションをすべて更新して再構築してから再起動します。 prestart だけではスーパーバイザ コードはリロードされません。復帰できるように、以前のデプロイメントと互換性のあるデータベースの移行を保持します。
PRNext は、部分的な Next.js 互換性を備えたアルファ版のままです。実験パスを個別に有効にして、コールド ロード、スタイル、ナビゲーション、アカウントの切り替え、アップロードの中断、依存関係の停止などの代表的なワークフローをテストします。関連するアップグレード ガイドでは、これらのチェックと各オプションの境界について詳しく説明しています。
出典と詳細情報
PRNext 0.1.20-alpha: published release (新しいタブで開きます)
PRNext 0.1.20: release source (新しいタブで開きます)
Experimental performance paths and React Compiler (新しいタブで開きます)
Compiler storage and deployment guide (新しいタブで開きます)
Health checks, rollback and monitoring (新しいタブで開きます)
Upgrade guide from 0.1.19 to 0.1.20 (新しいタブで開きます)