コンテンツにスキップ
ブログに戻る

2024年10月21日月曜日

Next.js 15

投稿者
Delba de Oliveira
Delba de Oliveira@delba_oliveira
Jimmy Lai
Jimmy Lai@feedthejim
Rich Haines
Rich Haines@studio_hungry

Next.js 15 は正式に安定版となり、本番環境での利用が可能になりました。このリリースは、RC1 および RC2 の両方のアップデートに基づいて構築されています。安定性に重点を置きつつ、皆様が気に入るであろうエキサイティングなアップデートも追加しました。ぜひ、今すぐ Next.js 15 をお試しください。

terminal
# Use the new automated upgrade CLI
npx @next/codemod@canary upgrade latest
 
# ...or upgrade manually
npm install next@latest react@rc react-dom@rc

また、今週木曜日、10月24日に開催される Next.js Conf で、今後の展望についてもさらに詳しくご紹介できることを楽しみにしています。

Next.js 15 の新機能は以下の通りです。

@next/codemod CLI によるスムーズなアップグレード

すべての Next.js のメジャーリリースには、破壊的変更のアップグレードを自動化するためのコードモッドが含まれています。

アップグレードをさらにスムーズにするために、拡張された codemod CLI をリリースしました。

ターミナル
npx @next/codemod@canary upgrade latest

このツールは、コードベースを最新の安定版またはプレリリース版にアップグレードするのに役立ちます。CLI は、依存関係を更新し、利用可能なコードモッドを表示し、それらを適用するプロセスをガイドします。

canary タグは最新のコードモッドバージョンを使用し、latest は Next.js のバージョンを指定します。最新の Next.js バージョンにアップグレードする場合でも、フィードバックに基づいてツールの改善を継続的に追加する予定であるため、canary バージョンのコードモッドの使用をお勧めします。

Next.js codemod CLI については、こちらで詳細をご覧ください。

非同期リクエスト API (破壊的変更)

従来のサーバーサイドレンダリングでは、サーバーはコンテンツをレンダリングする前にリクエストを待ちます。しかし、すべてのコンポーネントがリクエスト固有のデータに依存しているわけではないため、それらをレンダリングするためにリクエストを待つ必要はありません。理想的には、サーバーはリクエストが到着する前に可能な限り多くの準備を行うべきです。これを可能にし、将来の最適化の準備を整えるために、いつリクエストを待つ必要があるのかを知る必要があります。

そのため、headers、cookies、params、searchParams など、リクエスト固有のデータに依存する API を非同期に移行します。

import { cookies } from 'next/headers';
 
export async function AdminPanel() {
  const cookieStore = await cookies();
  const token = cookieStore.get('token');
 
  // ...
}

これは破壊的変更であり、以下の API に影響します。

  • cookies
  • headers
  • draftMode
  • layout.js、page.js、route.js、default.js、generateMetadata、generateViewport の params
  • page.js の searchParams

移行を容易にするために、これらの API は一時的に同期してアクセスできますが、開発および本番環境では次のメジャーバージョンまで警告が表示されます。移行を自動化する コードモッド が利用可能です。

ターミナル
npx @next/codemod@canary next-async-request-api .

コードモッドでコードを完全に移行できない場合は、アップグレードガイドをお読みください。また、Next.js アプリケーションを新しい API に移行する方法の 例 も提供しています。

キャッシングセマンティクス

Next.js App Router は、デフォルトでオピニオンのあるキャッシング設定で開始されました。これらは、必要に応じてオプトアウトできる機能とともに、デフォルトで最もパフォーマンスの高いオプションを提供するように設計されました。

皆様からのフィードバックに基づき、Partial Prerendering (PPR) のようなプロジェクトや、fetch を使用するサードパーティライブラリとの連携方法について、キャッシングヒューリスティクス を再評価しました。

Next.js 15 では、GET Route Handler および Client Router Cache のデフォルト設定を「キャッシュあり」から「キャッシュなし」に変更しました。以前の動作を維持したい場合は、引き続きキャッシュをオプトインできます。

今後数ヶ月かけてキャッシングの改善を続けていきますので、詳細については近日中に発表します。

GET Route Handler はデフォルトでキャッシュされなくなりました

Next 14 では、動的な関数または動的な設定オプションを使用しない限り、GET HTTP メソッドを使用する Route Handler はデフォルトでキャッシュされていました。Next.js 15 では、GET 関数はデフォルトでキャッシュされません。

export dynamic = 'force-static' のような静的ルート設定オプションを使用して、引き続きキャッシュをオプトインできます。

sitemap.ts、opengraph-image.tsx、icon.tsx などの特別な Route Handler、およびその他のメタデータファイルは、動的な関数または動的な設定オプションを使用しない限り、デフォルトで静的のままです。

ページコンポーネントはデフォルトでキャッシュされなくなりました

Next.js 14.2.0 では、staleTimes フラグを実験的に導入し、Router Cache のカスタム設定を可能にしました。

Next.js 15 では、このフラグは引き続き利用可能ですが、ページセグメントのデフォルト設定を staleTime 0 に変更しました。これにより、アプリ内をナビゲートする際に、クライアントはナビゲーションの一部としてアクティブになるページコンポーネントから最新のデータを常に反映します。ただし、変更されない重要な動作もいくつかあります。

  • 共有レイアウトデータは、部分レンダリングのサポートを継続するために、サーバーから再取得されません。
  • バック/フォワードナビゲーションは、ブラウザがスクロール位置を復元できるように、引き続きキャッシュから復元されます。
  • loading.js は、5分間 (または staleTimes.static 設定の値) キャッシュされたままになります。

以前の Client Router Cache の動作をオプトインするには、次の設定を行います。

next.config.ts
const nextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 30,
    },
  },
};
 
export default nextConfig;

React 19

Next.js 15 のリリースでは、今後の React 19 のリリースと連携することにしました。

バージョン 15 では、App Router は React 19 RC を使用し、コミュニティからのフィードバックに基づき Pages Router の React 18 との後方互換性も導入しました。Pages Router を使用している場合、準備ができ次第 React 19 にアップグレードできます。

React 19 はまだ RC フェーズですが、実際のアプリケーションでの広範なテストと React チームとの緊密な協力により、その安定性に自信を持っています。コアの破壊的変更は十分にテストされており、既存の App Router ユーザーには影響しません。そのため、Next.js 15 を本日安定版としてリリースし、皆様のプロジェクトが React 19 GA に完全に準備できるようにしました。

移行を可能な限りスムーズにするために、コードモッドと自動化ツールを提供し、移行プロセスを容易にしました。

Next.js 15 アップグレードガイド、React 19 アップグレードガイド、および React Conf Keynote をご覧ください。

Pages Router on React 18

Next.js 15 は、Pages Router と React 18 との後方互換性を維持し、ユーザーが Next.js 15 の改善点を利用しながら React 18 を引き続き使用できるようにします。

最初のリリース候補 (RC1) から、コミュニティからのフィードバックに基づき、React 18 のサポートを含めることに注力してきました。この柔軟性により、React 18 を使用している場合でも Next.js 15 を採用でき、アップグレードパスの制御が向上します。

注意: 1つのアプリケーションで Pages Router を React 18 で、App Router を React 19 で実行することは可能ですが、この構成は推奨しません。両バージョンの基盤となる API とレンダリングロジックが完全に一致しない可能性があるため、予期せぬ動作や型の一貫性の問題が発生する可能性があります。

React Compiler (実験的)

Meta の React チームによって作成された新しい実験的コンパイラであるReact Compilerは、プレーン JavaScript のセマンティクスとReact のルールを深く理解することで、コードを深く理解し、コードに自動的な最適化を追加できます。このコンパイラは、開発者が useMemo や useCallback のような API を介して手動で行う必要があるメモ化の量を減らし、コードをよりシンプルで、保守しやすく、エラーを起こしにくくします。

Next.js 15 では、React Compiler のサポートを追加しました。React Compiler と、利用可能な Next.js 設定オプション について詳しく学びましょう。

注意: React Compiler は現在 Babel プラグインとしてのみ利用可能であり、開発およびビルド時間が遅くなります。

ハイドレーションエラーの改善

Next.js 14.1 では、エラーメッセージとハイドレーションエラーを改善しました。Next.js 15 では、これらの改善をさらに進め、ハイドレーションエラービューを強化しました。ハイドレーションエラーは、エラーのソースコードと問題の対処方法に関する提案を表示するようになりました。

例えば、これは Next.js 14.1 でのエラーメッセージでした。

Hydration error message in Next.js 14.1

Next.js 15 では、これを改善しました。

Hydration error message improved in Next.js 15

Turbopack Dev

next dev --turbo が安定版となり、開発体験を高速化できることをお知らせできることを嬉しく思います。私たちは、vercel.com、nextjs.org、v0、およびその他のすべてのアプリケーションで、素晴らしい結果を伴って使用してきました。

例えば、vercel.com という大規模な Next.js アプリケーションでは、以下のような結果が見られました。

  • ローカルサーバーの起動が最大 76.7% 高速化。
  • Fast Refresh によるコード更新が最大 96.3% 高速化。
  • 初期ルートコンパイルがキャッシュなしで最大 45.8% 高速化 (Turbopack はまだディスクキャッシュを持っていません)。

Turbopack Dev については、新しいブログ記事で詳しく説明しています。

静的ルートインジケーター

Next.js は、開発中に静的ルートインジケーターを表示し、どのルートが静的か動的かを識別するのに役立ちます。この視覚的な手がかりにより、ページのレンダリング方法を理解することで、パフォーマンスの最適化が容易になります。

next build の出力を使用して、すべてのルートのレンダリング戦略を表示することもできます。

このアップデートは、Next.js のオブザーバビリティを強化するための継続的な取り組みの一環であり、開発者がアプリケーションを監視、デバッグ、最適化することを容易にします。また、専用の開発者ツールも開発中であり、詳細については近日中に発表します。

静的ルートインジケーターについて、こちらで詳細をご覧ください。無効にすることも可能です。

レスポンス後にコードを実行する unstable_after (実験的)

ユーザーリクエストを処理する際、サーバーは通常、レスポンスの計算に直接関連するタスクを実行します。しかし、ロギング、分析、その他の外部システム同期などのタスクを実行する必要がある場合があります。

これらのタスクはレスポンスに直接関連しないため、ユーザーはそれらが完了するのを待つ必要はありません。ユーザーへのレスポンス後に作業を遅延させることは、サーバーレス関数がレスポンスが閉じられた直後に計算を停止するため、課題となります。

after() は、レスポンスがストリーミング完了後に処理されるように作業をスケジュールできる新しい実験的 API であり、プライマリ レスポンスをブロックすることなくセカンダリ タスクを実行できるようにします。

使用するには、next.config.js に experimental.after を追加します。

next.config.ts
const nextConfig = {
  experimental: {
    after: true,
  },
};
 
export default nextConfig;

その後、Server Components、Server Actions、Route Handlers、または Middleware で関数をインポートします。

import { unstable_after as after } from 'next/server';
import { log } from '@/app/utils';
 
export default function Layout({ children }) {
  // Secondary task
  after(() => {
    log();
  });
 
  // Primary task
  return <>{children}</>;
}

unstable_after については、こちらで詳細をご覧ください。

instrumentation.js (安定版)

register() API を備えた instrumentation ファイルにより、ユーザーは Next.js サーバーライフサイクルにアクセスして、パフォーマンスを監視し、エラーの原因を追跡し、OpenTelemetry のようなオブザーバビリティライブラリと深く統合できます。

この機能は現在安定版となり、experimental.instrumentationHook 設定オプションを削除できます。

さらに、Sentry と協力して、以下の目的で使用できる新しい onRequestError フックを設計しました。

  • サーバーで発生したすべてのエラーに関する重要なコンテキストをキャプチャします。これには以下が含まれます。
    • ルーター: Pages Router または App Router
    • サーバーコンテキスト: 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() {
  // init your favorite observability provider SDK
}

onRequestError 関数については、こちらで詳細をご覧ください。

<Form> コンポーネント

新しい <Form> コンポーネントは、HTML の <form> 要素を、プリフェッチ、クライアントサイドナビゲーション、およびプログレッシブエンハンスメントで拡張します。

検索フォームから結果ページに移動する場合など、新しいページに移動するフォームに便利です。

app/page.jsx
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 がまだ読み込まれていない場合でも、フォームはフルページナビゲーションで機能します。

以前は、これらの機能を実現するには多くの手動ボイラープレートが必要でした。たとえば、

例
// Note: This is abbreviated for demonstration purposes.
// Not recommended for use in production code.
 
'use client'
 
import { useEffect } from 'react'
import { useRouter } from 'next/navigation'
 
export default function Form(props) {
  const action = props.action
  const router = useRouter()
 
  useEffect(() => {
    // if form target is a URL, prefetch it
    if (typeof action === 'string') {
      router.prefetch(action)
    }
  }, [action, router])
 
  function onSubmit(event) {
    event.preventDefault()
 
    // grab all of the form fields and trigger a `router.push` with the data URL encoded
    const formData = new FormData(event.currentTarget)
    const data = new URLSearchParams()
 
    for (const [name, value] of formData) {
      data.append(name, value as string)
    }
 
    router.push(`${action}?${data.toString()}`)
  }
 
  if (typeof action === 'string') {
    return <form onSubmit={onSubmit} {...props} />
  }
 
  return <form {...props} />
}

<Form> コンポーネントについては、こちらで詳細をご覧ください。

next.config.ts のサポート

Next.js は、TypeScript の next.config.ts ファイルタイプをサポートし、オートコンプリートと型安全なオプションのための NextConfig 型を提供します。

next.config.ts
import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  /* config options here */
};
 
export default nextConfig;

Next.js の TypeScript サポートについて詳細をご覧ください。

セルフホスティングの改善

アプリケーションをセルフホスティングする場合、Cache-Control ディレクティブの制御をさらに強化する必要がある場合があります。

一般的なケースの 1 つは、ISR ページに送信される stale-while-revalidate 期間を制御することです。2 つの改善を実装しました。

  1. next.config で expireTime 値を構成できるようになりました。これは以前は experimental.swrDelta オプションでした。
  2. デフォルト値を 1 年に更新し、ほとんどの CDN が stale-while-revalidate セマンティクスを意図したとおりに完全に適用できるようにしました。

また、カスタム Cache-Control 値をデフォルト値で上書きすることはなくなったため、完全な制御が可能になり、任意の CDN セットアップとの互換性が保証されます。

さらに、セルフホスティング時の画像最適化を改善しました。以前は、Next.js サーバーで画像を最適化するために sharp をインストールすることをお勧めしていました。この推奨事項は、見落とされることがありました。Next.js 15 では、sharp を手動でインストールする必要はなくなりました。Next.js は、next start を使用する場合や、スタンドアロン出力モードで実行する場合に sharp を自動的に使用します。

詳細については、セルフホスティング Next.js に関する新しい デモとチュートリアルビデオ を参照してください。

Server Actions のセキュリティ強化

Server Actions は、クライアントから呼び出すことができるサーバーサイド関数です。ファイルの一番上に 'use server' ディレクティブを追加し、非同期関数をエクスポートすることで定義されます。

Server Action またはユーティリティ関数がコードの他の場所でインポートされていなくても、公開可能な HTTP エンドポイントとして扱われます。この動作は技術的には正しいですが、このような関数の意図しない露出につながる可能性があります。

セキュリティを向上させるために、以下の強化を行いました。

  • デッドコード削除: 使用されていない Server Actions の ID はクライアントサイド JavaScript バンドルに公開されなくなり、バンドルサイズが縮小され、パフォーマンスが向上します。
  • セキュアなアクションID: Next.js は、クライアントが Server Actions を参照および呼び出すことができる、推測不可能で非決定的な ID を生成します。これらの ID は、セキュリティを強化するためにビルド間で定期的に再計算されます。
// app/actions.js
'use server';
 
// This action **is** used in our application, so Next.js
// will create a secure ID to allow the client to reference
// and call the Server Action.
export async function updateUserAction(formData) {}
 
// This action **is not** used in our application, so Next.js
// will automatically remove this code during `next build`
// and will not create a public endpoint.
export async function deleteUserAction(formData) {}

Server Actions は引き続き公開 HTTP エンドポイントとして扱ってください。Server Actions のセキュリティについては、こちらで詳細をご覧ください。

外部パッケージのバンドル最適化 (安定版)

外部パッケージのバンドルは、アプリケーションのコールドスタートパフォーマンスを向上させることができます。App Router では、外部パッケージはデフォルトでバンドルされ、新しい serverExternalPackages 設定オプションを使用して特定のパッケージをオプトアウトできます。

Pages Router では、外部パッケージはデフォルトでバンドルされませんが、既存の transpilePackages オプションを使用してバンドルするパッケージのリストを指定できます。この設定オプションでは、各パッケージを指定する必要があります。

App Router と Pages Router の間の設定を統一するために、App Router のデフォルトの自動バンドリングに一致する新しいオプション、bundlePagesRouterDependencies を導入しました。その後、必要に応じて serverExternalPackages を使用して特定のパッケージをオプトアウトできます。

next.config.ts
const nextConfig = {
  // Automatically bundle external packages in the Pages Router:
  bundlePagesRouterDependencies: true,
  // Opt specific packages out of bundling for both App and Pages Router:
  serverExternalPackages: ['package-name'],
};
 
export default nextConfig;

外部パッケージの最適化については、こちらで詳細をご覧ください。

ESLint 9 サポート

Next.js 15 は、ESLint 8 の 2024 年 10 月 5 日のサポート終了に伴い、ESLint 9 のサポートも導入します。

スムーズな移行を保証するために、Next.js は後方互換性を維持します。つまり、ESLint 8 または 9 のいずれかを引き続き使用できます。

ESLint 9 にアップグレードし、新しい設定形式をまだ採用していないことが検出された場合、Next.js は移行を容易にするために ESLINT_USE_FLAT_CONFIG=false エスケープハッチを自動的に適用します。

さらに、next lint を実行する際に、--ext や --ignore-path などの非推奨オプションは削除されます。ESLint 10 ではこれらの古い構成が最終的に許可されなくなるため、早めの移行を開始することをお勧めします。

これらの変更の詳細については、移行ガイド を参照してください。

このアップデートの一環として、eslint-plugin-react-hooks を v5.0.0 にアップグレードしました。これにより、React Hooks の使用に関する新しいルールが導入されました。すべての変更は、changelog for eslint-plugin-react-hooks@5.0.0 で確認できます。

開発とビルドの改善

Server Components HMR

開発中、Server Components は保存時に再実行されます。これは、API エンドポイントやサードパーティサービスへの fetch リクエストも呼び出されることを意味します。

ローカル開発のパフォーマンスを向上させ、課金対象 API 呼び出しの潜在的なコストを削減するために、Hot Module Replacement (HMR) が以前のレンダリングからの fetch レスポンスを再利用できるようにしました。

Server Components HMR Cache については、こちらで詳細をご覧ください。

App Router の静的生成の高速化

ビルド時間の短縮、特にネットワークリクエストが遅いページでのビルド時間を短縮するために、静的生成を最適化しました。

以前は、静的最適化プロセスでページが 2 回レンダリングされていました。1 回目はクライアントサイドナビゲーション用のデータを生成するため、2 回目は初回ページ訪問用の HTML をレンダリングするためです。現在は、最初のレンダリングを再利用し、2 回目のパスをカットアウトすることで、ワークロードとビルド時間を削減しています。

さらに、静的生成ワーカーはページ間で fetch キャッシュを共有するようになりました。fetch 呼び出しがキャッシュをオプトアウトしない場合、その結果は同じワーカーが処理する他のページで再利用されます。これにより、同じデータに対するリクエスト数が削減されます。

高度な静的生成制御 (実験的)

より高度な制御が必要なユースケースのために、静的生成プロセスに対するより多くの制御を提供する実験的なサポートを追加しました。

これらのオプションは、同時実行性の増加によるリソース使用量の増加やメモリ不足エラーの原因となる可能性があるため、特別な要件がない限り、現在のデフォルト設定を使用することをお勧めします。

next.config.ts
const nextConfig = {
  experimental: {
    // how many times Next.js will retry failed page generation attempts
    // before failing the build
    staticGenerationRetryCount: 1
    // how many pages will be processed per worker
    staticGenerationMaxConcurrency: 8
    // the minimum number of pages before spinning up a new export worker
    staticGenerationMinPagesPerWorker: 25
  },
}
 
export default nextConfig;

静的生成オプションについては、こちらで詳細をご覧ください。

その他の変更点

  • [破壊的変更] next/image: squoosh を削除し、オプションの依存関係として sharp を使用するように変更 (PR)
  • [破壊的変更] next/image: デフォルトの Content-Disposition を attachment に変更 (PR)
  • [破壊的変更] next/image: src に先頭または末尾のスペースがある場合のエラー (PR)
  • [破壊的変更] Middleware: 推奨されない React API のインポートを制限するために react-server 条件を適用 (PR)
  • [破壊的変更] next/font: 外部 @next/font パッケージのサポートを削除 (PR)
  • [破壊的変更] next/font: font-family ハッシュを削除 (PR)
  • [破壊的変更] キャッシング: force-dynamic は fetch キャッシュに no-store デフォルトを設定します (PR)
  • [破壊的変更] 設定: デフォルトで swcMinify (PR)、missingSuspenseWithCSRBailout (PR)、および outputFileTracing (PR) の動作をデフォルトで有効にし、非推奨オプションを削除します。
  • [破壊的変更] Speed Insights の自動インストルメンテーションを削除しました (専用の @vercel/speed-insights パッケージを使用する必要があります) (PR)
  • [破壊的変更] 動的な sitemap ルートの .xml 拡張機能を削除し、開発と本番環境間の sitemap URL を統一 (PR)
  • [破壊的変更] App Router での export const runtime = "experimental-edge" のエクスポートを非推奨にしました。ユーザーは代わりに export const runtime = "edge" に切り替える必要があります。この変更を実行するためのコードモッドを追加しました (PR)
  • [破壊的変更] レンダリング中に revalidateTag と revalidatePath を呼び出すと、エラーが発生するようになりました (PR)
  • [破壊的変更] instrumentation.js および middleware.js ファイルは、ベンダー化された React パッケージを使用するようになります (PR)
  • [破壊的変更] 必須の Node.js バージョンが 18.18.0 に更新されました (PR)
  • [破壊的変更] next/dynamic: 非推奨の suspense プロップが削除され、App Router でコンポーネントが使用される場合、空の Suspense 境界は挿入されなくなりました (PR)
  • [破壊的変更] Edge Runtime でモジュールを解決する際、worker モジュール条件は適用されなくなります (PR)
  • [破壊的変更] Server Components で next/dynamic で ssr: false オプションを使用することを禁止します (PR)
  • [改善] Metadata: Vercel でホストされる場合の metadataBase の環境変数フォールバックを更新しました (PR)
  • [改善] optimizePackageImports からの名前空間インポートと名前付きインポートの混在によるツリーシェイキングの修正 (PR)
  • [改善] Parallel Routes: マッチしないキャッチオールルートに、すべての既知のパラメータを提供 (PR)
  • [改善] bundlePagesExternals 設定が安定版となり、bundlePagesRouterDependencies に名前が変更されました。
  • [改善] serverComponentsExternalPackages 設定が安定版となり、serverExternalPackages に名前が変更されました。
  • [改善] create-next-app: 新しいプロジェクトは、デフォルトですべての .env ファイルを無視します (PR)
  • [改善] outputFileTracingRoot、outputFileTracingIncludes、および outputFileTracingExcludes が実験的段階から卒業し、安定版になりました (PR)
  • [改善] ツリーの奥深くにあるCSSモジュールファイルとグローバルCSSファイルをマージしないようにしました (PR)
  • [改善] キャッシュハンドラーは、NEXT_CACHE_HANDLER_PATH 環境変数で指定できるようになりました (PR)
  • [改善] Pages Router は、React 18 と React 19 の両方をサポートするようになりました (PR)
  • [改善] エラーオーバーレイに、インスペクターが有効な場合に Node.js インスペクター URL をコピーするボタンが表示されるようになりました (PR)
  • [改善] App Router のクライアントプリフェッチは、priority 属性を使用するようになりました (PR)
  • [改善] Next.js は、App Router で Next.js の内部エラーを再スローするための unstable_rethrow 関数を提供するようになりました (PR)
  • [改善] unstable_after は静的ページで使用できるようになりました (PR)
  • [改善] SSR 中に next/dynamic コンポーネントが使用された場合、チャンクはプリフェッチされます (PR)
  • [改善] App Router で esmExternals オプションがサポートされるようになりました (PR)
  • [改善] experimental.allowDevelopmentBuild オプションは、デバッグ目的で next build で NODE_ENV=development を許可するために使用できます (PR)
  • [改善] Server Action の変換は、Pages Router では無効になりました (PR)
  • [改善] ビルドワーカーは、終了時にビルドがハングするのを停止するようになりました (PR)
  • [改善] Server Action からリダイレクトする場合、再検証が正しく適用されるようになりました (PR)
  • [改善] Edge Runtime 上の Parallel Routes で動的パラメータが正しく処理されるようになりました (PR)
  • [改善] 静的ページは、初期ロード後に staleTime を尊重するようになりました (PR)
  • [改善] vercel/og にメモリリーク修正を適用しました (PR)
  • [改善] パッチタイミングを更新し、API モックなどのパッケージの使用を可能にしました (PR)
  • [改善] 事前レンダリングされたページは、静的 staleTime を使用するようになりました (PR)

詳細については、アップグレードガイドを参照してください。

コントリビューター

Next.js は、3,000 人以上の個人開発者、Google や Meta のような業界パートナー、そして Vercel のコアチームの共同作業の成果です。このリリースは、以下の方々によって提供されました。

ご協力いただいた皆様、@AbhiShake1, @Aerilym, @AhmedBaset, @AnaTofuZ, @Arindam200, @Arinji2, @ArnaudFavier, @ArnoldVanN, @Auxdible, @B33fb0n3, @Bhavya031, @Bjornnyborg, @BunsDev, @CannonLock, @CrutchTheClutch, @DeepakBalaraman, @DerTimonius, @Develliot, @EffectDoplera, @Ehren12, @Ethan-Arrowood, @FluxCapacitor2, @ForsakenHarmony, @Francoscopic, @Gomah, @GyoHeon, @Hemanshu-Upadhyay, @HristovCodes, @HughHzyb, @IAmKushagraSharma, @IDNK2203, @IGassmann, @ImDR, @IncognitoTGT, @Jaaneek, @JamBalaya56562, @Jeffrey-Zutt, @JohnGemstone, @JoshuaKGoldberg, @Julian-Louis, @Juneezee, @KagamiChan, @Kahitar, @KeisukeNagakawa, @KentoMoriwaki, @Kikobeats, @KonkenBonken, @Kuboczoch, @Lada496, @LichuAcu, @LorisSigrist, @Lsnsh, @Luk-z, @Luluno01, @M-YasirGhaffar, @Maaz-Ahmed007, @Manoj-M-S, @ManuLpz4, @Marukome0743, @MaxLeiter, @MehfoozurRehman, @MildTomato, @MonstraG, @N2D4, @NavidNourani, @Nayeem-XTREME, @Netail, @NilsJacobsen, @Ocheretovich, @OlyaPolya, @PapatMayuri, @PaulAsjes, @PlagueFPS, @ProchaLu, @Pyr33x, @QiuranHu, @RiskyMH, @Sam-Phillemon9493, @Sayakie, @Shruthireddy04, @SouthLink, @Strift, @SukkaW, @Teddir, @Tim-Zj, @TrevorSayre, @Unsleeping, @Willem-Jaap, @a89529294, @abdull-haseeb, @abhi12299, @acdlite, @actopas, @adcichowski, @adiguno, @agadzik, @ah100101, @akazwz, @aktoriukas, @aldosch, @alessiomaffeis, @allanchau, @alpedia0, @amannn, @amikofalvy, @anay-208, @andrii-bodnar, @anku255, @ankur-dwivedi, @aralroca, @archanaagivale30, @arlyon, @atik-persei, @avdeev, @baeharam, @balazsorban44, @bangseongbeom, @begalinsaf, @bennettdams, @bewinsnw, @bgw, @blvdmitry, @bobaaaaa, @boris-szl, @bosconian-dynamics, @brekk, @brianshano, @cfrank, @chandanpasunoori, @chentsulin, @chogyejin, @chrisjstott, @christian-bromann, @codeSTACKr, @coderfin, @coltonehrman, @controversial, @coopbri, @creativoma, @crebelskydico, @crutchcorn, @darthmaim, @datner, @davidsa03, @delbaoliveira, @devjiwonchoi, @devnyxie, @dhruv-kaushik, @dineshh-m, @diogocapela, @dnhn, @domdomegg, @domin-mnd, @dvoytenko, @ebCrypto, @ekremkenter, @emmerich, @flybayer, @floriangosse, @forsakenharmony, @francoscopic, @frys, @gabrielrolfsen, @gaojude, @gdborton, @greatvivek11, @gnoff, @guisehn, @GyoHeon, @hamirmahal, @hiro0218, @hirotomoyamada, @housseindjirdeh, @hungdoansy, @huozhi, @hwangstar156, @iampoul, @ianmacartney, @icyJoseph, @ijjk, @imddc, @imranolas, @iscekic, @jantimon, @jaredhan418, @jeanmax1me, @jericopulvera, @jjm2317, @jlbovenzo, @joelhooks, @joeshub, @jonathan-ingram, @jonluca, @jontewks, @joostmeijles, @jophy-ye, @jordienr, @jordyfontoura, @kahlstrm, @karlhorky, @karlkeefer, @kartheesan05, @kdy1, @kenji-webdev, @kevva, @khawajaJunaid, @kidonng, @kiner-tang, @kippmr, @kjac, @kjugi, @kshehadeh, @kutsan, @kwonoj, @kxlow, @leerob, @lforst, @li-jia-nan, @liby, @lonr, @lorensr, @lovell, @lubieowoce, @luciancah, @luismiramirez, @lukahartwig, @lumirlumir, @luojiyin1987, @mamuso, @manovotny, @marlier, @mauroaccornero, @maxhaomh, @mayank1513, @mcnaveen, @md-rejoyan-islam, @mehmetozguldev, @mert-duzgun, @mirasayon, @mischnic, @mknichel, @mobeigi, @molebox, @mratlamwala, @mud-ali, @n-ii-ma, @n1ckoates, @nattui, @nauvalazhar, @neila-a, @neoFinch, @niketchandivade, @nisabmohd, @none23, @notomo, @notrab, @nsams, @nurullah, @okoyecharles, @omahs, @paarthmadan, @pathliving, @pavelglac, @penicillin0, @phryneas, @pkiv, @pnutmath, @qqww08, @r34son, @raeyoung-kim, @remcohaszing, @remorses, @rezamauliadi, @rishabhpoddar, @ronanru, @royalfig, @rubyisrust, @ryan-nauman, @ryohidaka, @ryota-murakami, @s-ekai, @saltcod, @samcx, @samijaber, @sean-rallycry, @sebmarkbage, @shubh73, @shuding, @sirTangale, @sleevezip, @slimbde, @soedirgo, @sokra, @sommeeeer, @sopranopillow, @souporserious, @srkirkland, @steadily-worked, @steveluscher, @stipsan, @styfle, @stylessh, @syi0808, @symant233, @tariknh, @theoludwig, @timfish, @timfuhrmann, @timneutkens, @tknickman, @todor0v, @tokkiyaa, @torresgol10, @tranvanhieu01012002, @txxxxc, @typeofweb, @unflxw, @unstubbable, @versecafe, @vicb, @vkryachko, @wbinnssmith, @webtinax, @weicheng95, @wesbos, @whatisagi, @wiesson, @woutvanderploeg, @wyattjoh, @xiaohanyu, @xixixao, @xugetsu, @yosefbeder, @ypessoa, @ytori, @yunsii, @yurivangeffen, @z0n, @zce, @zhawtof, @zsh77、そして @ztanner に感謝いたします！