PRNext および Next.js: 互換性および移行ガイド

#バージョンと前提条件を調整する

このリリースでは、ノード ^22.23.4 || を宣言します。 ^24.22.1 || >=26.12.1. その React、React DOM および React-server-dom-webpack ピアは 19.3.1. です。 オプションのネイティブ依存関係を有効にしておきます。ネイティブ コンポーネントはフレームワークのバージョンと一致する必要があります。

以下のコマンドは npm を使用します。プロジェクトで既に使用されている場合は、pnpm または Yarn を保持し、パッケージに同梱されているドキュメントをお読みください。元のロックファイルを保持したまま、ブランチまたは分離されたコピーで作業します。公開されたネイティブ パッケージでは、消費者が Rust をインストールする必要はありません。

node --version
npm install --save-exact @thomas.f/prnext@0.1.18-alpha react@19.3.1 react-dom@19.3.1 react-server-dom-webpack@19.3.1
npx --no-install prnext migrate --dry-run
npx --no-install prnext migrate --check --json

#集中的なチェックが必要な機能を特定する

ルーティング規則、サーバー コンポーネント、アクション、ナビゲーション、スタイルなどは、PRNext によって適応される領域です。スコープは構成と実行されるパスによって異なります。このマトリックスは、各機能ファミリーに普遍的な互換性を割り当てるのではなく、アプリケーション チェックを識別します。

#移行を適用する前に計画を読む

ドライランでは、提案されたスクリプトと依存関係の変更を確認できます。監査では、構成とソースの競合も特定する必要があります。 next.config.* または prnext.config.* ファイルを 1 つ保持します。名前を変更しても、不明な Next.js オプションはサポートされません。

計画が適切であれば、移行を適用し、構成を確認してビルドします。 typecheck には、アプリケーションに TypeScript と tsconfig が必要です。移行ではソースと Next.js が保持されます。 public next/* import はそのままにすることができます。一括インポート置換や --force によるピア競合の非表示を避けてください。

npx --no-install prnext migrate
npx --no-install prnext check --json
npx --no-install prnext typecheck
npx --no-install prnext build

#別々のサーバーからの応答を比較する

使用可能なポートで Next.js 参照を開始し、別のポートで候補を開始します。 paths.json には、アプリケーションのパスに置き換えられた、["/"、"/products/demo"、"/api/health"] などの具体的なルートの JSON 配列が含まれています。 Cookie や秘密情報をそこに入れないでください。

コンパレーターは、パブリック GET 応答のサンプルをチェックします。リクエストの認証やリダイレクトの追跡は行いません。そのタイミングは管理されたベンチマークではありません。良好な結果を得るには、依然としてブラウザーでスタイル、ハイドレーション、突然変異、認証状態をチェックする必要があります。

npx --no-install prnext migrate --check --against http://127.0.0.1:3000 --candidate http://127.0.0.1:3001 --routes paths.json

#製品が機能するまでの道のりを検証する

ログイン、ログアウト、およびビジネス アクションを実行します。ナビゲーション、エラー、読み込み状態、Cookie をもう一度確認してください。フォームの場合は、保存された結果と応答後の表示状態の両方を確認します。 HTTP ステータスはインタラクション全体を説明するものではありません。

2 つのセッションで分離チェックを追加します。プライベート応答とキャッシュされたデータがセッション間で交差してはなりません。プライベート Next.js インポート、カスタム ローダー、または高度なルーティングを使用する場合は、テストされたパスの最小限の例を保持してください。これらの依存関係によって評価が変わる可能性があります。

#機能検証後に決定

正確なバージョン、ロックファイル、テストされたケース、および非互換性を保持します。機能が欠落している場合は、API と関連するシナリオを特定します。全体的な互換性のパーセンテージよりも、正確な制限の方が役立ちます。

次に、一致するリソース制約の下で高価なルートを測定します。候補者が基準を満たすまで、リファレンスを保管してください。データベースの移行には独自のロールバック計画が必要です。 package.json を復元しても元に戻されません。

アプリケーションの要件に合わせて PRNext を選択してください

機能検証後に SSR を測定する