ClaudeNext.js2020/05/11 15:00

Next.js 9.4

要点だけを先に読めるように短く再構成したセクションです。

元記事

Quick Digest

要約

要点だけを先に読めるように短く再構成したセクションです。

claudejamodel: claude-sonnet-4-20250514

Next.js 9.4リリース - Fast Refreshと増分静的再生成を含む大型アップデート

Key Points

  • Fast Refreshでコンポーネント状態を保持した高速開発
  • 増分静的再生成でデプロイ後のページ更新が可能
  • 環境変数とfetch APIサポートの大幅改善

Summary

Next.js 9.4では、開発体験の大幅な向上と静的サイト生成の新機能が追加されました。Fast Refreshによる高速なホットリロード、増分静的再生成(ベータ版)による既存ページの動的更新、環境変数サポートの改善などが含まれています。

Key Points

  • Fast Refresh: React Refreshと深く統合し、コンポーネント状態を保持しながら瞬時にコード変更を反映
  • 増分静的再生成(ベータ版): unstable_revalidateオプションでデプロイ後に静的ページを背景で再生成
  • 環境変数サポート: .envファイルの標準サポートとNEXT_PUBLIC_プレフィックスによるブラウザ公開
  • fetch API改善: Node.js環境でもfetch()が利用可能、外部ライブラリ不要
  • Web Vitals統合: reportWebVitals関数でCore Web Vitalsメトリクスを収集
  • 絶対インポート: baseUrlpaths設定で相対パス地獄を解決
  • Sass設定: sassOptionsでincludePathsなどの詳細設定が可能
  • CMSサンプル: Contentful、DatoCMS、Prismic、Sanity、TakeShapeとの連携例を提供

Full Translation

翻訳

原文の流れを保ったまま読める翻訳セクションです。

claudejamodel: claude-sonnet-4-20250514

Next.js 9.4

Next.js 9.4

2020年5月11日(月)に投稿

投稿者: JJ Kasper @ _ijjk、Joe Haddad @ timer150、Luis Alvarez @ luis_fades、Shu Uesugi @ chibicode、Tim Neutkens @ timneutkens

本日、Next.js 9.4をご紹介できることを嬉しく思います。以下の機能を搭載しています:

  • Fast Refresh: Facebookスケールで実証された、高速で信頼性の高いライブ編集体験
  • Incremental Static Regeneration(ベータ版): デプロイ後に静的ページをミリ秒単位で再構築
  • CMSサンプル: 新世代の静的サイト生成を使用したContentful、DatoCMS、Prismic、Sanity、TakeShapeのサンプル
  • 新しい環境変数サポート: .envの組み込みサポートとNEXT_PUBLIC_プレフィックス(CRAで見られるような)
  • 改善された組み込みFetchサポート: Node.jsとすべてのブラウザ(ビルド時とランタイム)向けの組み込みfetchポリフィルにより、node-fetchやisomorphic-fetchのインポートが不要
  • 統合されたWeb Vitalsレポート: Lighthouseスコアを駆動するメトリクスを実際のトラフィックから取得
  • 絶対インポートとエイリアス: ../../../スパゲッティを避けた、より明確で短いインポート
  • 設定可能なSassサポート: 組み込みSassサポートのincludePathsやその他のオプションを設定
  • 改善されたログ出力: 読みやすく、一貫してフォーマットされ、繰り返しの少ないコンソール出力

Fast Refresh

Fast Refreshは、Reactコンポーネントに加えた編集に対して瞬時にフィードバックを提供する新しいホットリロード体験です。Next.js 9.4以降のすべてのプロジェクトでデフォルトで有効になっています。

ホットリロードは長い間存在していましたが、歴史的にワークフローでデフォルトで有効にするには脆弱すぎました。このため、Next.jsは以前、アプリケーション全体の状態をリセットする粗いホットリロードを実装していました。

古いホットリロード実装は、コンパイルエラーやランタイムエラーに対して耐性がなく、CSSやJavaScriptの編集中にタイプミスをした場合、アプリケーション全体のリロードを実行していました。これは最適ではなく、思考の流れを中断していました。

Fast RefreshはReact自体(React Refreshを介して)に深く統合されており、Next.jsがReactコンポーネントツリーに対して予測可能な精密更新を実行できるようになります。これは、Next.jsが編集したファイル内のコードのみを更新し、コンポーネントの状態を失うことなく、そのコンポーネントのみを再レンダリングすることを意味します。これには、スタイル(インライン、CSS-in-JS、またはCSS/Sassモジュール)、マークアップ、イベントハンドラー、エフェクト(useEffectを介して)が含まれます。

この体験の一部として、エラーオーバーレイをより有用で、アプリケーションをタイプミスやランタイムエラーに対して耐性があるものにするために完全に再設計しました。これには以下が含まれますが、これらに限定されません:

  • 正確なエラー位置: コンパイル前のコードの元の行と列に解決
  • 文脈的に関連するソースコードスニペット: エディターでクリックして開く機能付き
  • 構文エラー修正後の開発セッション再開: アプリケーション状態を失うことなく
  • 未処理のランタイムエラーの自動解除: エラーを修正したとき

この機能の実装において貴重な貢献と支援をしてくれたDan Abramovに感謝します。

Incremental Static Regeneration(ベータ版)

Next.jsは9.3で静的サイト生成メソッドを導入し、明確な目標を念頭に置いていました:静的(常に高速、常にオンライン、グローバルに分散)の利点を得つつ、Next.jsで知られている動的データの優れたサポートを提供することです。

両方の世界の最良の部分を得るために、Next.jsはIncremental Static Generationをサポートし、サイトを既に構築した後に静的コンテンツを更新します。

例えば、9.3ではgetStaticPathsfallback: trueオプションを導入し、ランタイムで新しいページを追加できるようにしました。最近、Next.jsがこの方法で無限数のページを静的に事前レンダリングできることを示すサンプルをまとめました。

本日、Incremental Static Regeneration(ベータ版)も導入します。これは、トラフィックが来るときにバックグラウンドで再レンダリングすることで既存のページを更新するメカニズムです。

stale-while-revalidateにインスパイアされ、これによりトラフィックが中断されることなく、常に静的に提供され、新しく構築されたページは生成が完了した後にのみプッシュされることが保証されます。

// pages/blog/[slug].js
export async function getStaticProps() {
  return {
    props: await getDataFromCMS(),
    // ページの再生成を試行します:
    // - リクエストが来たとき
    // - 最大で1秒に1回
    unstable_revalidate: 1,
  };
}

SSRとは異なり、Incremental Static Regenerationは静的の利点を保持することを保証します:

  • レイテンシのスパイクなし: ページは一貫して高速に提供されます
  • ページがオフラインになることがない: バックグラウンドページの再生成が失敗した場合、古いページは変更されません
  • データベースとバックエンドの負荷が低い: ページは最大で同時に1回だけ再計算されます

両方のインクリメンタル機能(ページの追加と遅延更新)、およびプレビューモードは、next startとVercelエッジプラットフォームの両方で既に完全にサポートされています。

次に、2つの追加のインクリメンタル静的生成機能に対処するための補足RFCに取り組む予定です:

  • 複数のページを一度に再生成・無効化(ブログインデックスと特定のブログ投稿など)
  • イベントをリスニングして再生成(CMSウェブフックなど)、ユーザートラフィックより先に

CMSサンプル

次世代静的サイト生成の発表に続いて、ヘッドレスCMS APIからコンテンツを取得し、Next.js HTMLとしてレンダリングする実世界のシナリオを共有したいと思いました。

世界最高のCMSシステムの作成者と提携しました:Contentful、DatoCMS、Prismic、Sanity、TakeShape、さらに多くが予定されています。

これらのサンプルは使用準備が整っており、100%オープンソースでMITライセンスであるだけでなく、利用可能なベストプラクティスを組み込んでいます:

DatoCMSは、組み込み画像最適化サポートにより完璧な結果を達成しています。

また、CMSの新しい方向性について、TinaCMSと協力しています:コンテンツのページ内編集です。プロジェクトに実装する方法については、彼らのガイドをご覧ください。

新しい環境変数サポート

Next.jsを使用している企業からの一般的なフィードバックは、環境変数がいつブラウザバンドルにインライン化され、いつNode.js環境でのみ利用可能かが不明確だということでした。

本日、このプロセスを合理化するのに役立つ2つの完全に後方互換性のある機能を発表します。

まず、環境変数にNEXT_PUBLIC_プレフィックスを付けることで、環境変数をブラウザに公開できるようになりました。その環境変数が使用されると、ブラウザJavaScriptバンドルにインライン化されます。これらの変数を公開するためにnext.config.jsを追加し、envキーを追加する必要がなくなりました。

// pages/index.js
// 環境変数はブラウザに公開されます
console.log('My Application Version', process.env.NEXT_PUBLIC_VERSION);

export default function HomePage() {
  return <h1>Hello World</h1>;
}

2番目の変更は、Next.jsがデフォルトで.envローディングをサポートするようになったことです。これにより、開発環境と本番環境の環境変数を簡単に定義できます。

.envローディングの詳細については、環境変数ドキュメントをご覧ください。

これらの新機能は、以下の規則に従うことで環境変数の使用を簡素化します:

  • 環境変数はデフォルトでNode.js環境でのみ利用可能
  • NEXT_PUBLIC_プレフィックスが付いた環境変数はブラウザに公開

改善された組み込みFetchサポート

Next.js 9.1.7で、ブラウザでのfetch() APIのポリフィルを発表しました。本日、このポリフィルはNode.js環境にも拡張されました。

実際には、Next.jsがすべての環境で自動的にfetch()を提供するため、サーバーサイドfetchポリフィル(例:isomorphic-unfetchnode-fetch)を使用する必要がなくなりました。

例えば、Next.jsでビルド時に実行されるgetStaticPropsを使用する場合:

// pages/blog.js
export async function getStaticProps() {
  // fetchはisomorphic-unfetchからインポートする必要がなくなりました
  const res = await fetch('https://.../posts');
  const posts = await res.json();

  return {
    props: {
      posts,
    },
  };
}

function Blog({ posts }) {
  // 投稿をレンダリング...
}

export default Blog;

統合されたWeb Vitalsレポート

先週、Google ChromeチームがCore Web Vitalsを導入しました。Core Web Vitalsは、ウェブで優れたUXを提供するための重要な品質シグナルであり、有名なLighthouseレポートの基盤となっています。

これらのメトリクスを追跡することは、ウェブサイトやウェブアプリケーションを可能な限り高速にしたい場合に非常に有用であり、これはNext.jsの中核目標の1つです。

Chromeチームは、開発者としてページのパフォーマンスに関する視覚的フィードバックを得ることができるCore Web Vitals Chrome拡張機能をリリースしました。

本番ウェブアプリケーションを構築する際、訪問者や(潜在的な)顧客に対してサイトがどのようにパフォーマンスしているかを知りたいと思うでしょう。変更が対象者に意図した影響を与えているかどうかを確認するために、これらのメトリクスの改善や回帰を時間の経過とともに追跡したい場合もあります。

Core Web Vitalsをアナリティクスサービスにレポートすることを支援するため、Googleと協力して、pages/_app.jsからエクスポートできるreportWebVitalsという新しいメソッドを導入しました:

// pages/_app.js
// レポートする必要があるすべてのメトリクスに対して一度呼び出されます。
export function reportWebVitals(metric) {
  // これらのメトリクスは任意のアナリティクスサービスに送信できます
  console.log(metric);
}

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}

export default MyApp;

このメソッドをアナリティクスサービスと組み合わせて使用するには、ドキュメントの「結果をアナリティクスに送信」セクションを参照してください。

Core Web Vitalsについて詳しく学びたい場合は、web.dev/vitalsを参照してください。

絶対インポートとエイリアス

大規模なプロジェクトで作業している場合、一部のインポート文が../../../スパゲッティに悩まされる可能性があります:

import Button from '../../../../components/button';

このような場合、相対インポートの代わりに絶対インポートを使用したい場合があります。componentsディレクトリがルートに存在すると仮定すると、インポート文を次のようにしたい場合があります:

import Button from 'components/button';

Next.js 9.4では、JavaScriptとTypeScriptプロジェクトの両方で絶対インポートの設定が非常に簡単になったことを発表できて嬉しく思います。必要なのは、jsconfig.json(JSプロジェクト)またはtsconfig.json(TSプロジェクト)にbaseUrl設定を追加することだけです。

// jsconfig.json / tsconfig.json
{
  "compilerOptions": {
    "baseUrl": "."
  }
}

これにより、.(ルートディレクトリ)からの絶対インポートが可能になります。また、VSCodeやその他のエディターと統合され、コードナビゲーションやその他のエディター機能をサポートします。

注意:絶対インポートを有効にするために以前にWebpackモジュールエイリアス設定を変更していた場合、その設定は削除できます。

さらに、Next.js 9.4はpathsオプションもサポートしており、カスタムモジュールエイリアスを作成できます。例えば、以下ではcomponents/design-systemの代わりに@/design-systemを使用できます:

// jsconfig.json / tsconfig.json
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/design-system/*": ["components/design-system/*"]
    }
  }
}

その後、エイリアスを次のように使用できます:

// 'components/design-system/button'をインポート
import Button from '@/design-system/button';

pathsを指定する場合はbaseUrlを指定する必要があります。pathsオプションの詳細については、TypeScriptドキュメントをご覧ください。

設定可能なSassサポート

Next.js 9.3で組み込みSassサポートが開始されたとき、ユーザーの一部がsassコンパイラーを設定したいというフィードバックを受けました。例えば、includePathsを設定するためです。

これは、next.config.jssassOptionsキーを使用することで可能になりました: