バンドラーとは？多数のモジュールを少数のファイルに変える

バンドラーはモジュールグラフを辿り、すべての import を解決し、ブラウザがダウンロードして実行できる少数の最適化されたファイルを出力します。

現代の Web アプリは何百、何千もの小さなモジュールとして書かれますが、それだけの数のファイルをブラウザに出荷するのは遅くなります。バンドラーはエントリーポイントを読み、すべての import を辿り、その結果をひと握りの出力ファイルに縫い合わせます。これはフロントエンド pipeline で最も遅いステップの一つであり、CI でキャッシュの主要な対象になります。

バンドラーが実際に行うこと

エントリーポイントから始めて、バンドラーは import を通じて到達可能なすべてのモジュールの依存関係グラフを構築します。それから、パスを解決し、アセットをインライン化または参照し、途中で変換を適用しながら、それらのモジュールを出力ファイルに連結して書き換えます。

なぜバンドリングがブラウザにとって重要か

すべてのモジュールを個別に読み込むよりネットワークリクエストが少ない。
デッドコードを削除できるので、ユーザーのダウンロードが減る。
出力をキャッシュ可能な chunk に分割できる。
画像や CSS のようなアセットは、長期キャッシュのためにフィンガープリントされる。

一般的なバンドラー

Webpack、Rollup、esbuild、Vite、Parcel はすべてバンドルしますが、速度と設定が異なります。esbuild と Vite は速い dev build を重視し、Rollup はクリーンなライブラリ出力を重視し、Webpack は大規模なレガシーアプリで依然として一般的です。

出力 artifact

本番 bundle は通常、ハッシュ化された JS、CSS、アセットファイルに HTML エントリを加えた dist/ または build/ フォルダです。そのフォルダは、pipeline が CDN や static host にアップロードするデプロイ可能な artifact です。

CI/CD でのバンドリング

pipeline では、バンドリングは依存関係のインストール後、deploy 前に実行されます。CPU とメモリを多く使うため、実行間で node_modules とバンドラーの cache をキャッシュすることで恩恵を受けます。cache のない cold な runner は、毎回フルコストを支払います。

bundle build を速く保つ

依存関係とバンドラーの cache を実行間で永続化することが、最大の勝利です。マネージド runner（Latchkey など）はそれらの cache を warm に保つため、bundle ステップはすべての pipeline 実行でゼロから始まりません。

重要なポイント

バンドラーはエントリーポイントから import を辿り、少数の最適化されたファイルを出力します。
出力フォルダは、pipeline がデプロイする artifact です。
バンドリングは遅くキャッシュに敏感なので、CI では warm cache が重要です。