Backブログに戻る

Next.js 5.1: 高速なページ解決、環境設定など

Next.js 5.1では、環境設定、フェーズ、ソースマップ、新しいNext.jsプラグインのサポートが追加されました。

Next.js 5.1のリリースを発表します。このバージョンでは環境設定、フェーズ、ソースマップ、新しいNext.jsプラグインのサポートが追加されました。

主要なパフォーマンス改善として、ページ解決が102倍高速化され、エラーページの読み込みがより効率的になりました。

アップグレードまたはインストールするには、以下を実行してください:

Terminal
npm i next@latest react@latest react-dom@latest

Next.jsのアップグレードに加えて、peer dependenciesであるreactreact-domもアップグレードされます

@zeit/next-css@zeit/next-sass@zeit/next-less@zeit/next-typescriptなどのnext-pluginsも忘れずにアップグレードしてください。

高速なページ解決

Next.js 5.0のアーキテクチャ変更により、URLパスに基づいてページを解決するロジックを簡素化することができました。これらの変更は@oliviertassinari調査に基づいています。以前はページ解決に平均2.347msかかっていましたが、新しいロジックでは同じページの解決に平均0.023msしかかかりません。これはNext.jsアプリケーションで最も頻繁に呼び出されるメソッドの1つが102倍高速化されたことを意味します。

リクエストごとのページ解決時間。左がNext.js 5.0、右がNext.js 5.1

リクエストごとのページ解決時間。左がNext.js 5.0、右がNext.js 5.1

環境設定

一般的なNode.js環境では、アプリケーションに環境変数を渡すことがよくあります。例: API_URL=https://api.vercel.com node index.js そして process.env.API_URL を使ってアプリケーション内で API_URL を使用できます。

ユニバーサルレンダリングでは process.env はクライアントサイドで利用できません。そこでNext 5.1では新しい機能として publicRuntimeConfigserverRuntimeConfig を導入しました。これらは next.config.js で設定でき、next/config モジュールを使って利用できます。

next.config.js
module.exports = {
  serverRuntimeConfig: {
    // サーバーサイドでのみ利用可能
    mySecret: 'secret',
  },
  publicRuntimeConfig: {
    // サーバーとクライアントの両方で利用可能
    staticFolder: '/static',
  },
};

serverRuntimeConfigpublicRuntimeConfignext.config.js で定義されます

pages/index.js
import getConfig from 'next/config';
const { serverRuntimeConfig, publicRuntimeConfig } = getConfig();
 
console.log(serverRuntimeConfig.mySecret); // サーバーサイドでのみ利用可能
console.log(publicRuntimeConfig.staticFolder); // サーバーとクライアントの両方で利用可能
 
export default function Index() {
  return (
    <div>
      <img src={`${publicRuntimeConfig.staticFolder}/logo.png`} />
    </div>
  );
}

next/config モジュールの getConfig メソッドを使って設定値を取得します

改善されたエラーハハンドリング

以前のNext.jsには、ページバンドルを読み込む際のサーバーエラーを検出する特別なエラーハンドリングメカニズムがありました。ページバンドルとは、クライアントサイドでページを読み込むために読み込まれるJavaScriptファイルです(例: /_next/-/page/index.js)。

ビルドIDの不一致などのエラーがあった場合、ページバンドルは200 HTTPステータスで配信されますが、内容はNext.jsサーバーによって生成されたエラーのJSON表現になります。この理由は、ページが404であること以上のクライアントサイドのエラーハンドリングに依存していたためです。このソリューションは、フォールバックをサポートしていない静的ファイルホストやCDNにアセットをアップロードしようとするまで非常にうまく機能していました。

Next.js 5.1では、エラーハンドリングロジックを完全に再構築しました。ページバンドルが404 HTTPステータスを返すと、ルーターが自動的にそれを検出してページをリロードし、マルチゾーン間のナビゲーションが可能になるようにします。

このロジックの書き換えにより、Router.onAppUpdatedフックが削除されました。このフックは主にページリロードをトリガーするために使用されていました。現在はページが自動的にリロードされます。

これに加えて、開発モードでのエラー回復に関する新しい統合テストを追加し、将来のリリースでエラー回復に関するリグレッションを防ぎます。

フェーズ/設定関数

@zeit/next-cssのようなnext-pluginsの中には、Next.jsが開発モードにあるときやnext buildを実行しているときにのみ必要なものがあります。

これからは、設定オブジェクトを即座にエクスポートする代わりに、設定オブジェクトを返す関数をエクスポートできます。

module.exports = (phase, { defaultConfig }) => config;

ユーザー設定を返す関数をエクスポートするnext.config.js

関数をエクスポートすると、Next.jsが実行されているphase(開発、本番、ビルド、エクスポートなど)にアクセスできます。これにより、プラグインが必要なときにのみロードできるだけでなく、デフォルト設定にもアクセスできます。

一般的に使用される定数(フェーズを含む)を保持するnext/constantsという新しいモジュールを導入しました。

const {PHASE_DEVELOPMENT_SERVER} = require('next/constants')
module.exports = (phase, {defaultConfig}){
  if(phase === PHASE_DEVELOPMENT_SERVER) {
    return { /* 開発専用の設定オプションをここに記述 */ }
  }
 
  return { /* 開発以外のすべてのフェーズの設定オプションをここに記述 */ }
}

開発フェーズをチェックするnext.config.js

改善された本番用ソースマップ生成

Next.js 5でユニバーサルwebpackが導入されたことで、本番環境にソースマップを追加することがnext.config.jsに数行追加するだけで簡単になりました:

next.config.js
module.exports = {
  webpack(config, { dev }) {
    if (!dev) {
      config.devtool = 'source-map';
      for (const plugin of config.plugins) {
        if (plugin['constructor']['name'] === 'UglifyJsPlugin') {
          plugin.options.sourceMap = true;
          break;
        }
      }
    }
    return config;
  },
};

next.config.jsで手動でソースマップを有効化

@zeit/next-source-mapsをプロジェクトに追加すると、本番用ソースマップを自動的に有効にできます。next.config.jsに以下を追加してください:

const withSourceMaps = require('@zeit/next-source-maps');
module.exports = withSourceMaps();

@zeit/next-source-mapsを使ってnext.config.jsでソースマップを有効化

これにより、1つのファイルapp.jsを除くすべてのファイルのソースマップが出力されるようになりました。その理由は、app.jsが複数のファイル(manifest.jscommons.js)とwebpackプラグインで構成されていたためです。この副作用として、webpackは結合されたファイルのソースマップを生成できませんでした。

@ptomasroosによるプルリクエストのおかげで、app.jsファイルがmain.jsに置き換えられました。このファイルには以前manifest.jscommons.jsにコンパイルされていたコードが保持され、webpackはmain.jsのソースマップを生成します。ソースマップは自動的に提供され、外部エラートラッキングツールがエラーを検出したときに実際のファイルと行番号を表示できるようになります。

ソースパネルに表示されたソースコード

ソースパネルに表示されたソースコード

新しいプラグイン/既存プラグインの改善

2つの新しい公式プラグインを導入しました。@zeit/next-bundle-analyzerを使うと、webpack-bundle-analyzerを簡単に設定して、サーバーサイドとクライアントサイドのバンドルを別々に分析できます。

さらに、公式のcsslesssassプラグインに関して、ホットリロードとバンドリングに関する多くの改善がありました。例えば、開発モードでのスタイル未適用コンテンツのちらつきがなくなりました。また、サブコンポーネントのスタイルも認識されるようになりました。

コミュニティ

現在、Next.jsコミュニティはGitHubで見つけることができます。最近、Next.jsを使用している注目すべき企業のリストが投稿されました。スレッドにプロジェクトを自由に投稿してください。

謝辞

このリリースに貢献してくれたすべての方々に感謝します。コアへの貢献であろうと、ますます成長しているexamplesディレクトリの拡張と改善であろうと、すべての貢献に感謝します。

Next.jsへの貢献を始めたい場合は、good first issueまたはhelp wantedラベルの付いたissueを見つけることができます。

環境設定と新しいエラーページ処理に関する貴重なフィードバックを提供してくれたTruliaに特に感謝します。