Next.js 9.1 | Next.js

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

このリリースにおける新機能

src ディレクトリのサポート: pages ディレクトリを src フォルダの下にネストできるようになり、より広範なアプリケーション設定をサポートします。
public ディレクトリのサポート: アプリケーションの URL のルートにマウントするファイル (例: favicon.ico) を定義します。

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

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

これまで同様、これらの利点がすべて後方互換性を持つように努めています。更新するには、以下のコマンドを実行するだけです。

ターミナル

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

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

前回のメジャーリリース以降、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 と呼ばれるもう1つの特別なディレクトリがあり、そのファイルは /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% がこのプラグインをアプリケーションに追加していることがわかりました。

この広範な使用状況を考慮し、開発時のスタイルの自動リロードや、以前は next-css プラグインでは不可能だったプロダクション最適化を含む、CSS インポートの組み込みサポートを追加します。

初期実装は現在、本番のNext.jsアプリケーションでテストされています。

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

pages/_app.js

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

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

pages/index.js

// 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 と呼ばれています。このページは、pages/_error.js ファイルを作成して React コンポーネントをエクスポートすることで、ユーザーがカスタマイズできます。

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

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

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

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

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

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

Google Chromeとのコラボレーション

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

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

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%で使用されている場合、共通モジュールとしてマークされます。

しかし、アプリケーションは様々な要素で構成されている場合があります。例えば、マーケティングページ、ブログ、ダッシュボードなどです。ダッシュボードと比較してマーケティングページの数が非常に多い場合、コモンズの計算はマーケティングページにより最適化された結果をもたらすことになります。

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

Alex Castle は、複数ファイルでの、特に多くのページが関与する場合において、より最適化されたコモンズチャンキングを可能にする、新しいチャンキング層（個別の JavaScript ファイルの作成）を定義しました。

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

コミュニティ

すべての Next.js アプリケーションのパフォーマンスを向上させる今後の変更に期待しています。

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

800人以上のコントリビューターが少なくとも1コミットをしています。
GitHub では、プロジェクトが41,350回以上スターされています。
examples ディレクトリには210以上の例があります。

Next.js コミュニティは現在、11,250人以上のメンバーを擁しています。ぜひご参加ください！

今回のリリースを形作るのに貢献してくださったコミュニティ、そしてすべての外部からのフィードバックと貢献に感謝いたします。