Next.js 9.1
本日、srcディレクトリとpublicディレクトリのサポートを含むNext.js 9.1の発表を嬉しく思います。
このリリースの新機能
- srcディレクトリサポート: pagesディレクトリをsrcフォルダ内にネストできるようになり、より幅広いアプリケーション構成をサポートします。
- publicディレクトリサポート: アプリケーションのURLのルートにマウントするファイル（例：favicon.ico）を定義できます。
このリリースでプレビュー中
- 組み込みCSSサポート: アプリケーションでグローバルCSSをインポートし、開発時のホットリロードと高度な本番最適化、コンパイル、ポリフィルを活用できるようになります。
- 静的エラーページ: 期待されるエラーページ（404など）を静的にエクスポートして、可用性を向上させます（CDN）。
- Module / Nomodule: モダンブラウザで実行されるエンドユーザーに、より小さなJavaScriptバンドルを配信します。
- 改善されたバンドル分割: エンドユーザーに送信するバイト数を削減し、TTIとページ遷移速度を向上させます。大きなライブラリチャンクもデプロイ間で長期キャッシュされます。
常に、これらすべての利点が後方互換性を保つよう努めています。更新するために必要なのは以下のコマンドを実行することだけです：
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ディレクトリの使用はオプションであり、会社でこの標準がすでに導入されている場合をカバーします。
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%がこのプラグインをアプリケーションに追加していることがわかりました。
この広範な使用により、開発時のスタイルの自動リロードと、next-cssプラグインでは以前不可能だった本番最適化を含む、CSSインポートの組み込みサポートを追加しています。
初期実装は現在、本番のNext.jsアプリケーションでテストされています。
グローバルCSSインポートが最初に導入されます：
import '../styles/global.css';
import App from 'next/app';
export default App;
グローバルCSSインポートの後、.module.css拡張子を通じて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ターゲットを使用する際のコストが削減されます。
ページを静的にするもう一つの利点は、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%で使用されている場合、共通モジュールとしてマークされます。
しかし、アプリケーションは多くの異なる部分から構成される可能性があります。例えば、マーケティングページ、ブログ、ダッシュボードなどです。ダッシュボードと比較してマーケティングページが多数ある場合、commons計算はマーケティングページにとってより最適化された結果を引き起こします。
私たちの目標は、一つのアプリケーションでこれらの両方を同時に最適化することです。
Alex Castleは、複数のファイルでより最適化されたcommons分割を可能にし、特に多くのページが関与する場合の新しいチャンキング（個別のJavaScriptファイルの作成）レイヤーを定義しました。
module/nomoduleサポートと同様に、改善されたバンドル分割は実世界のデータを収集するために複数の大規模Next.jsアプリケーションで本番テストされています。これらのテストの結果とこの変更のパフォーマンス改善に関する詳細は、近日中に別のブログ投稿で共有される予定です。
コミュニティ
すべてのNext.jsアプリケーションのパフォーマンスを向上させる今後の変更について興奮しています。さらに、Next.jsコミュニティは引き続き拡大しています：
- 少なくとも1つのコミットを行った800人以上のコントリビューターがいます
- GitHubでプロジェクトは41,350回以上スターされています
- examplesディレクトリには210以上の例があります
- Next.jsコミュニティには現在11,250人以上のメンバーがいます
ぜひご参加ください！
このリリースの形成に貢献したコミュニティとすべての外部フィードバックと貢献に感謝しています。