本日、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@latestNext.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ディレクトリの使用は任意で、すでにこの標準がある企業のケースをカバーします。
srcディレクトリ内のpagesフォルダ
publicディレクトリサポート
pagesディレクトリに加えて、Next.jsにはstaticという特別なディレクトリがあり、そのファイルは/staticルートにマッピングされていました。
例えば、static/my-image.pngは/static/my-image.pngにマッピングされます。
この規約はNext.jsの最初のリリース以来うまく機能しており、特に問題はありませんでした。
しかし、時間の経過とともに、/staticがウェブアプリケーションに必要なすべてをカバーしていないことがわかりました。例えば、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を基盤とした既存のスタイリングやデザインシステムを再利用する必要性が共通していることがわかりました。
一般的に、これはnext-cssプラグインを追加してCSSインポートサポートを実現することを意味します。
約50%のNext.jsユーザーがこのプラグインをアプリケーションに追加していることがわかりました。
この広範な使用状況を受けて、CSSインポートの組み込みサポートを追加し、開発時のスタイル自動リロードと、以前はnext-cssプラグインでは不可能だったプロダクション最適化を実現します。
最初の実装は現在、プロダクションNext.jsアプリケーションでテスト中です。
最初にグローバルCSSインポートが導入されます:
// グローバルスタイルは_app.jsからインポートできます
import '../styles/global.css';
import App from 'next/app';
export default App;グローバルCSSインポートの後、.module.css拡張子を通じてCSSモジュールのサポートが導入されます:
// スコープされたスタイルは.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の発表を読むか、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の計算はマーケティングページに対してより最適化された結果をもたらします。
私たちの目標は、1つのアプリケーション内でこれら両方を同時に最適化することです。
Alex Castleは、より多くのページが関与する場合に特に、複数のファイルでより最適化されたcommonsチャンキング（個別のJavaScriptファイルの作成）を可能にする新しいチャンキングレイヤーを定義しました。
module/nomoduleサポートと同様に、改善されたバンドル分割は複数の大規模Next.jsアプリケーションで実稼働環境でテストされ、実世界のデータを収集しています。これらのテストの結果とこの変更によるパフォーマンス改善の詳細は、別のブログ投稿で近日中に共有される予定です。
コミュニティ
すべてのNext.jsアプリケーションのパフォーマンスを向上させる今後の変更に興奮しています。
さらに、Next.jsコミュニティはまだ拡大しています:
- 800人以上のコントリビューターが少なくとも1つのコミットをしています。
- GitHubでは、プロジェクトが41,350回以上スターされています。
- examplesディレクトリには210以上の例があります。
Next.jsコミュニティには現在11,250人以上のメンバーがいます。ぜひ参加してください！
このリリースを形作るのに役立った外部からのフィードバックと貢献、そして私たちのコミュニティに感謝しています。