Next.js 15 RC 2
5月に最初のNext.js 15リリース候補を発表して以来、皆様からのフィードバックに基づいて第2のリリース候補を準備してきました。以下が私たちが取り組んできた内容です：
- @next/codemod upgrade: 最新のNext.jsとReactバージョンへの簡単なアップグレード
- Turbopack for development: パフォーマンス改善とNext.js 15安定性目標
- Async Request APIs（破壊的変更）: 簡素化されたレンダリングとキャッシュモデルへの段階的ステップ
- Server Actions: 推測不可能なエンドポイントと未使用アクションの削除による強化されたセキュリティ
- Static Indicator: 開発中に静的ルートを表示する新しいビジュアルインジケーター
- next/form: クライアントサイドナビゲーションでHTMLフォームを強化
- next.config.ts: Next.js設定ファイルのTypeScriptサポート
- instrumentation.js（安定版）: サーバーライフサイクル監視のための新しいAPI
- 開発とビルドの改善: ビルド時間の改善とより高速なFast Refresh
- セルフホスティング: Cache-Controlヘッダーのより多くの制御
- リンティング: ESLint 9のサポート追加
Next.js 15リリース候補（RC2）を今すぐ試す
npx @next/codemod@canary upgrade rc
npm install next@rc react@rc react-dom@rc
注意: このリリース候補には前回のRCからのすべての変更が含まれています。
codemod CLIによるスムーズなアップグレード
破壊的変更のアップグレードを自動化するため、すべてのメジャーNext.jsリリースにcodemod（自動コード変換）を含めています。アップグレードをさらにスムーズにするため、強化されたcodemod CLIをリリースしました：
npx @next/codemod@canary upgrade rc
このツールは、コードベースを最新の安定版またはプレリリース版にアップグレードするのに役立ちます。CLIは依存関係を更新し、利用可能なcodemodを表示し、それらの適用をガイドします。
コマンドラインで指定されたdistタグ（@rc、@canaryなど）がアップグレード先のバージョンを決定します。
Next.js codemodについて詳しく学ぶ
開発用Turbopack
ローカル開発用のTurbopackは、Next.js 15の一般リリースで安定版となり、オプトインのままです。今すぐ以下を実行して試すことができます：
next dev --turbo
Turbopackベータ版とリリース候補フェーズを通じてテスト、問題報告、修正の検証に参加した数千人の開発者のおかげで、最初のNext.js 15リリース候補以来54のGitHub issueを解決しました。
このコミュニティの努力と並行して、vercel.com、v0.app、nextjs.orgでの内部テストにより、数多くの追加改善を特定しました。
過去3か月間、コールドコンパイルパフォーマンスの最適化に焦点を当てました。前回のリリースと比較して、以下を確認しました：
- メモリ使用量25-35%削減
- 数千のモジュールを持つ大きなページのコンパイルが30-50%高速化
今後のリリースでもこれらの領域の最適化を続けます。
今後の展望として、Turbopackチームは永続キャッシュ、メモリ使用量削減、next build用Turbopackで大きな進歩を遂げており、96%のテストが合格しています。
注意: Turbopackのサポートされている機能とサポートされていない機能
をすべて確認してください。
Async Request APIs（破壊的変更）
従来のサーバーサイドレンダリングでは、サーバーはコンテンツをレンダリングする前にリクエストを待ちます。しかし、すべてのコンポーネントがリクエスト固有のデータに依存するわけではないため、それらをレンダリングするためにリクエストを待つ必要はありません。
理想的には、サーバーはリクエストが到着する前にできるだけ多くを準備します。これを可能にし、将来の最適化の基盤を設定するため、リクエストをいつ待つかを知る必要があります。
したがって、headers、cookies、params、searchParamsなどのリクエスト固有のデータに依存するAPIを非同期に移行しています。
import { cookies } from 'next/headers';
export async function AdminPanel() {
const cookieStore = await cookies();
const token = cookieStore.get('token');
}
これは破壊的変更であり、以下のAPIに影響します：
cookiesheadersdraftModelayout.js、page.js、route.js、default.js、generateMetadata、generateViewportのparamspage.jsのsearchParams
移行を簡単にするため、これらのAPIは一時的に同期的にアクセスできますが、次のメジャーバージョンまで開発環境と本番環境で警告が表示されます。
移行を自動化するcodemodが利用可能です：npx @next/codemod@canary next-async-request-api
codemodがコードを完全に移行できない場合は、アップグレードガイドをお読みください。
新しいAPIにNext.jsアプリケーションを移行する方法の例も提供しています。
Server Actionsの強化されたセキュリティ
Server Actionsは、クライアントから呼び出すことができるサーバーサイド関数です。ファイルの先頭に'use server'ディレクティブを追加し、async関数をエクスポートすることで定義されます。
Server Actionやユーティリティ関数がコード内の他の場所でインポートされていなくても、それは依然として公開アクセス可能なHTTPエンドポイントです。この動作は技術的には正しいですが、そのような関数の意図しない露出につながる可能性があります。
セキュリティを向上させるため、以下の強化を導入しました：
- デッドコード除去: 未使用のServer ActionsのIDはクライアントサイドJavaScriptバンドルに露出されず、バンドルサイズを削減し、パフォーマンスを向上させます
- セキュアなアクションID: Next.jsは、クライアントがServer Actionを参照して呼び出すことを可能にする推測不可能で非決定的なIDを作成します。これらのIDは、セキュリティ強化のためビルド間で定期的に再計算されます
'use server';
export async function updateUserAction(formData) {}
export async function deleteUserAction(formData) {}
Server Actionsは依然としてパブリックHTTPエンドポイントとして扱う必要があります。
Server Actionsのセキュリティについて詳しく学ぶ
静的ルートインジケーター
Next.jsは開発中に静的ルートインジケーターを表示し、どのルートが静的または動的かを識別するのに役立ちます。このビジュアルキューにより、ページがどのようにレンダリングされるかを理解してパフォーマンスを最適化することが容易になります。
next build出力を使用してすべてのルートのレンダリング戦略を表示することもできます。
この更新は、Next.jsの監視性を強化する継続的な取り組みの一部であり、開発者がアプリケーションを監視、デバッグ、最適化することを容易にします。専用の開発者ツールにも取り組んでおり、詳細は近日公開予定です。
静的ルートインジケーターについて詳しく学ぶ（無効にすることも可能）
<Form>コンポーネント
新しい<Form>コンポーネントは、HTML <form>要素をプリフェッチ、クライアントサイドナビゲーション、プログレッシブエンハンスメントで拡張します。検索フォームが結果ページにつながるような、新しいページにナビゲートするフォームに有用です。
import Form from 'next/form';
export default function Page() {
return (
<Form action="/search">
<input name="query" />
<button type="submit">Submit</button>
</Form>
);
}
<Form>コンポーネントには以下が含まれます：
- プリフェッチ: フォームが表示されると、レイアウトとローディングUIがプリフェッチされ、ナビゲーションが高速になります
- クライアントサイドナビゲーション: 送信時に、共有レイアウトとクライアントサイド状態が保持されます
- プログレッシブエンハンスメント: JavaScriptがまだロードされていない場合でも、フォームはフルページナビゲーションで動作します
以前は、これらの機能を実現するには多くの手動ボイラープレートが必要でした。
<Form>コンポーネントについて詳しく学ぶ
next.config.tsのサポート
Next.jsはTypeScript next.config.tsファイルタイプをサポートし、オートコンプリートとタイプセーフオプションのためのNextConfigタイプを提供します：
import type { NextConfig } from 'next';
const nextConfig: NextConfig = {
};
export default nextConfig;
Next.jsでのTypeScriptサポートについて詳しく学ぶ
instrumentation.js（安定版）
register() APIを持つinstrumentationファイルにより、ユーザーはNext.jsサーバーライフサイクルにタップして、パフォーマンスを監視し、エラーの原因を追跡し、OpenTelemetryなどの監視ライブラリと深く統合できます。
この機能は安定版となり、experimental.instrumentationHook設定オプションは削除できます。
さらに、Sentryと協力して新しいonRequestErrorフックを設計しました。これは以下に使用できます：
- サーバーで発生したすべてのエラーに関する重要なコンテキストをキャプチャ：
- Router: Pages RouterまたはApp Router
- Server context: Server Component、Server Action、Route Handler、またはMiddleware
- お気に入りの監視プロバイダーにエラーを報告
export async function onRequestError(err, request, context) {
await fetch('https://...', {
method: 'POST',
body: JSON.stringify({
message: err.message,
request,
context
}),
headers: {
'Content-Type': 'application/json'
},
});
}
export async function register() {
}
onRequestError関数について詳しく学ぶ
開発とビルドの改善
Server Components HMR
開発中、Server componentsは保存時に再実行されます。これは、APIエンドポイントやサードパーティサービスへのfetchリクエストも呼び出されることを意味します。
ローカル開発パフォーマンスを向上させ、課金されるAPI呼び出しの潜在的コストを削減するため、Hot Module Replacement（HMR）が以前のレンダリングからのfetchレスポンスを再利用できるようになりました。
Server Components HMRキャッシュについて詳しく学ぶ
App Routerの高速静的生成
特に低速なネットワークリクエストを持つページのビルド時間を改善するため、静的生成を最適化しました。以前は、静的最適化プロセスはページを2回レンダリングしていました—1回目はクライアントサイドナビゲーション用のデータを生成し、2回目は初回ページ訪問用のHTMLをレンダリングしていました。
現在は最初のレンダリングを再利用し、2回目のパスを削除して、作業負荷とビルド時間を削減しています。
さらに、静的生成ワーカーはページ間でfetchキャッシュを共有するようになりました。fetchコールがキャッシュをオプトアウトしない場合、その結果は同じワーカーによって処理される他のページで再利用されます。これにより、同じデータに対するリクエスト数が削減されます。
高度な静的生成制御（実験的）
より大きな制御が有益な高度なユースケース向けに、静的生成プロセスのより多くの制御に対する実験的サポートを追加しました。これらのオプションは同時実行性の増加により、リソース使用量の増加とメモリ不足エラーの可能性につながる可能性があるため、特定の要件がない限り現在のデフォルトを使用することをお勧めします。
const nextConfig = {
experimental: {
staticGenerationRetryCount: 1,
}
};