Next.js 9.1 | Next.js

本日、Next.js 9.1 のリリースを発表できることを嬉しく思います。このリリースでは src および public ディレクトリのサポートが追加されました。

今回のリリースでの新機能

src ディレクトリのサポート: pages ディレクトリを src フォルダ内にネストできるようになり、より多様なアプリケーション構成をサポートします。
public ディレクトリのサポート: アプリケーションの URL のルートにマウントされるファイルを定義します（例：favicon.ico）。

このリリースでのプレビュー

組み込み CSS サポート: アプリケーションでグローバル CSS をインポートできるようになり、開発時のホットリロードと、高度な本番環境の最適化、コンパイル、ポリフィルを活用できます。
静的エラーページ: 404 などの予期されるエラーページを静的にエクスポートして、可用性（CDN）を向上させます。
Module / Nomodule: Evergreen ブラウザで実行されているエンドユーザーに、より小さい JavaScript バンドルを配信します。
バンドル分割の改善: エンドユーザーに配信されるバイト数を減らし、TTI（Time To Interactive）とページ遷移速度を向上させます。大規模なライブラリチャンクは、デプロイ間で長期的にキャッシュされます。

例のごとく、これらのすべてのメリットが後方互換性を確保するように努めています。更新するために必要なのは、実行するだけです。

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

アプリケーションが 9 より前のバージョンの Next.js を使用している場合は、アップグレードで変更が必要になる可能性のある内容について、アップグレードガイドを参照してください。

前回のメジャーリリース以降、TikTok、Hilton、Elastic、Realtor、JW Player のような企業が Next.js を利用してローンチしたことを嬉しく思います。さらに多くの事例は、ショーケースでご確認ください！

`src` ディレクトリのサポート

Next.js には特別な pages ディレクトリがあり、各ファイルが個別のルートになります。規約重視のアプローチに従い、このディレクトリは Next.js アプリケーションのルートに配置する必要があります。

Next.js を使用している企業との会話や、一部のクローズドソースのコードベースを調査した結果、開発者が望む一般的なパターンとして、コード用の src ディレクトリを持ち、その中に pages ディレクトリも配置するというものがありました。

Next.js 9.1 から、アプリケーションのルートに pages ディレクトリを作成する代わりに、src/pages ディレクトリを作成できるようになりました。

src ディレクトリの使用はオプションであり、すでにその標準が導入されている企業の場合に対応します。

The pages folder in the src directory directory — src ディレクトリ内の pages フォルダー

`public` ディレクトリのサポート

pages ディレクトリ以外に、Next.js には static というもう一つの特別なディレクトリがありますが、そのファイルは /static ルートにマッピングされていました。

例えば、static/my-image.png は /static/my-image.png にマッピングされます。

この規約は Next.js の最初のリリース以来うまく機能しており、特に問題はありません。

しかし、時間とともに、/static では Web アプリケーションに必要なすべてをカバーできないことがわかりました。例えば、robots.txt はドメインのルートから配信される必要があります。

Next.js 9.1 から、public という新しいディレクトリを導入します。

public ディレクトリ内のファイルは、ドメインのルートにマッピングされます。

例えば、public/robots.txt は /robots.txt にマッピングされます。

public は static ディレクトリのユースケースもカバーするため、同じ機能を持つ public/static フォルダを作成することに取って代わる形で、static ディレクトリを非推奨とすることにしました。

例のごとく、後方互換性を確保するよう努めているため、static ディレクトリは非推奨メッセージとともに引き続き機能します。

近日公開

以下の機能は現在実験的なフラグの下にあり、最終的な実装が準備でき次第リリースされます。

組み込み CSS サポート

現在、Next.js には styled-jsx という組み込みの CSS-in-JS ソリューションがあります。このソリューションは、個々の React コンポーネントのスタイリングにうまく機能します。

しかし、企業との会話の中で、既存のスタイリングや CSS ベースのデザインシステムを再利用したいという共通のニーズがあることがわかりました。

一般的に、これは CSS インポートサポートを追加するために next-css プラグインを追加することを意味します。

Next.js ユーザーの約 50% がこのプラグインをアプリケーションに追加していることがわかりました。

この広範な使用状況のため、CSS インポートの組み込みサポートを、開発時の自動リロードと、以前は next-css プラグインでは不可能だった高度な本番環境の最適化とともに提供します。

初期実装は現在、多数の本番 Next.js アプリケーションでテストされており、最終的な実装の準備が整い次第リリースされます。

まずグローバル CSS インポートが導入されます。

// Global styles can be imported from _app.js
import '../styles/global.css';
import App from 'next/app';
 
export default App;

グローバル CSS インポートの後、.module.css 拡張子による CSS モジュールのサポートを導入します。

// Scoped styles are imported through .module.css
import styles from '../styles/index.module.css';
 
export default function HomePage() {
  return <h1 className={styles.heading}>Hello World</h1>;
}

これにより、CSS インポートを使用する際の開発者エクスペリエンスを大幅に向上させることができます。

進行中の作業については、GitHub の RFC で詳細をご確認いただけます。

静的エラーページ

Next.js には、エラー発生時にレンダリングされる特別なページがあり、内部的には /_error と呼ばれます。このページは、React コンポーネントをエクスポートする pages/_error.js ファイルを作成することで、ユーザーがカスタマイズできます。

レンダリングされるエラーは、一般的に、予期されるエラーと予期しないエラーの 2 つのケースに分けられます。

予期されるエラーとは、例えば 404 ページのことです。

予期しないエラーとは、例えば、getInitialProps でエラーが発生した場合や、React ツリーのレンダリング中にエラーが発生した場合など、500 がレンダリングされる場合です。

予期されるエラーは、一般的に動的にレンダリングする必要がないため、それらに対する自動静的最適化を追加する予定です。

これらのページを動的にレンダリングしたいユーザーのためにオプトアウト機能が用意されますが、デフォルトでは 404 は静的ページになります。これにより、server ターゲットを使用する際のサーバー負荷が軽減され、serverless ターゲットを使用する際のコストが削減されます。

ページを静的にすることのもう 1 つの利点は、CDN を使用する際に自動的にキャッシュできることです。

Google Chrome コラボレーション

Next.js 9 の発表で共有されたように、Google Chrome チームは Next.js の改善にリソースを投資しており、すべての Next.js アプリケーションのパフォーマンスを大規模に向上させるための複数の取り組みを進めています。

このコラボレーションの詳細については、Next.js 9 の発表を参照し、Nicole Sullivan の React Rally でのこの講演をご覧ください。

Module / Nomodule

Next.js でコードを書く場合、一般的には「モダン」な JavaScript を使用します。最新の安定した機能すべてを使用でき、Next.js は Babel を使用してコードをコンパイルすることにより、これらの機能が変換またはポリフィルされることを自動的に保証します。

この時点で、これらの JavaScript 機能の多くはほとんどのブラウザでサポートされています。しかし、一般的に（Next.js も含めて）、コードは、アプリケーションがサポートするすべてのブラウザで実行される単一の JavaScript バンドルとして配信されます。

Next.js の場合、これはモダンな JavaScript を Internet Explorer 11 と互換性のある形式にコンパイルすることを意味します。

例えば、現在 Next.js は async/await 構文のポリフィルを提供する必要があります。これは、async/await をサポートしていないブラウザでコードが実行されると、破損する可能性があるためです。

古いブラウザを破損させることなく、新しい構文をサポートするブラウザにモダンな JavaScript を送信するために、Next.js は module/nomodule パターンを利用します。module/nomodule パターンは、モダンなブラウザにモダンな JavaScript を提供し、古いブラウザがポリフィルされた ES5 コードにフォールバックできるようにする信頼性の高いメカニズムを提供します。

この新しい機能は現在、複数の大規模な Next.js アプリケーションで本番環境でテストされており、実際のデータを収集しています。これらのテストの結果は有望であり、この変更によるパフォーマンスの改善に関する詳細は近日中に共有されます。

バンドル分割の改善

現在、Next.js ではページをインタラクティブにするために複数の JavaScript バンドルをロードしています。最も注目すべきは、

ページ JavaScript バンドル。
共通 JavaScript を含むファイル。
Next.js クライアントサイドランタイムバンドル。
動的インポート（通常は next/dynamic を介して追加されます）。

ページがインタラクティブになるためには、これらのバンドルすべてをロードする必要があります。なぜなら、ブラウザで React を起動するには、それらがすべて相互に依存しているからです。

React が起動するためにこれらのバンドルをロードする必要があるため、それらが可能な限り最適化されており、アプリケーションの他の部分から過剰なコードをダウンロードしないことが重要です。

このため、ページ間で共通の JavaScript を保持する commons バンドルがあります。commons を生成するための現在のバンドル分割戦略の計算は、比率ベースのヒューリスティックに基づいています。モジュールがすべてのページの 50% で使用されている場合、共通モジュールとしてマークされます。

しかし、アプリケーションは多くの異なる部分から構成される可能性があります。例えば、マーケティングページ、ブログ、ダッシュボードなどです。ダッシュボードと比較してマーケティングページが多数ある場合、 commons の計算により、マーケティングページにより最適化された結果が得られます。

私たちの目標は、これらの両方を 1 つのアプリケーションで同時に最適化することです。

Alex Castle は、複数のファイル、特に多数のページが関与する場合に、より最適化された commons チャンクを可能にする、新しいチャンク（個別の JavaScript ファイルの作成）のレイヤーを定義しました。

module/nomodule サポートと同様に、改善されたバンドル分割は、複数の大規模な Next.js アプリケーションによって本番環境でテストされており、実際のデータを収集しています。これらのテストの結果と、この変更によるパフォーマンスの改善に関する詳細は、近日中に別のブログ投稿で共有されます。

コミュニティ

すべての Next.js アプリケーションのパフォーマンスを向上させる今後の変更に、私たちは興奮しています。

さらに、Next.js コミュニティは拡大を続けています。

少なくとも 1 つのコミットを記録した800人以上の貢献者がいました。
GitHub では、プロジェクトは41,350回以上スターを獲得しています。
examples ディレクトリには210以上の例があります。

Next.js コミュニティには現在11,250人以上のメンバーがいます。参加しましょう！

We are thankful to our community and all the external feedback and contributions that helped shape this release.