1.前置き
ここ最近、下記シリーズを書いたりする中で、Viteという比較的新しいビルドツールについて少し勉強していました。勉強する中で、Viteを使用した開発環境の構築は一通り行ってきましたが、ふと「Viteは本番環境でどう使うんだろう」というのが気になりました。この記事はその時調べたものの備忘録的な意味合いが強いです。そして、「Viteの本番環境の設定Tips」もこの記事では扱いません。あくまで、Viteが採用している技術に焦点を当てて、学んだことをまとめただけの記事になります。書いている人が理解しきれていない部分があるので、わかりにくいとこや表現として微妙なとこ、そもそも間違っているところあるかもです。悪しからず。
2.Viteは本番環境にどんな技術を使っているのか
Viteが採用している技術について少し調べると、その特筆すべき点として「devとprodで同じビルドというプロセスにそれぞれ異なるツールを使用していること」が挙げられているのがわかります。それぞれdevにはesbuildというgo製のビルドツールを、本番環境ではrollupというJS製のバンドラを採用しているようです。普通に考えれば「なんでそんなややこしいことするんだよ」と思ってもおかしくないと思いますが、Viteはなぜこのようなスタイルをとっているのでしょうか。Viteのドキュメントによれば、
Vite's current plugin API isn't compatible with using esbuild as a bundler. In spite of esbuild being faster, Vite's adoption of Rollup's flexible plugin API and infrastructure heavily contributed to its success in the ecosystem. For the time being, we believe that Rollup offers a better performance-vs-flexibility tradeoff.
esbuildは非常に速くなっているのだけれど、私たちはRollupの柔軟なプラグインAPIとインフラを採用することで、そのエコシステム内における成功に大いに貢献しています。(意訳)
rollupに肩入れしているようですね。ではなぜ、Viteはrollupに肩入れするのか、
Even though native ESM is now widely supported, shipping unbundled ESM in production is still inefficient (even with HTTP/2) due to the additional network round trips caused by nested imports. To get the optimal loading performance in production, it is still better to bundle your code with tree-shaking, lazy-loading and common chunk splitting (for better caching).
nativeESMは広くサポートされているけれど、本番環境において未バンドル状態のESMを扱うことは、ネットワークオーバーヘッドの観点から効率的でないようです。ESMにはモジュール構造をうまく使って、事前に依存関係のみバンドルし、都度ファイル全体をバンドルしないという特徴がありました。しかし、そのようなやり方はdevで使用されるesbuildのように、ブラウザからのリクエストに従って都度部分を更新することになります。そうしたやり方に対して、rollupに分がある、いまだに従来の事前にバンドルして最適化(tree-shaking,cacheのためのチャンク分割)を行うやり方の方が本番環境においてはbetterだといっています。
3.Viteの課題
ただやはり、こうしたハイブリッドな戦略をとることで困った点もあるようです。以下Vite ConfでのEvan You氏の説明がとてもわかりやすかったです。
まとめると、
・esbuildによるcommonjsそのものの扱い方とrollupによるそれらをESMに変換した後のmoduleの扱いが僅かに一致しないことがしばしばある。この違いはユーザーのdebugを難しくしている
・開発中における未バンドルESMのネットワークオーバーヘッドの問題もある
大きなプロジェクトを持つユーザーは、バンドルされていない大量のESMが最終的に最初のページの読み込みスピードに影響を与える
proxyの後ろで開発している利用者にとっては、特によくない
・rollupはesbuildに比べて非常に柔軟である一方で、webpackと比べると、prod環境におけるchunkのフルカスタマイズができるといった点ではwebpackのとても強力なcode spliting optionには及ばない
esbuild(bunの欠点)
早いけど、build assetの最適化がかなり制限される
chunkをsplitする手段がない
plugin APIの柔軟性が十分でない
rollupの欠点
native ESMバンドラに比べると遅い
ESM/CJSの相互運用性に改善の余地あり
そしてRolldownへ
以上述べたような背景から現在、Rspackというviteと似たような思想を持った製品チームのコアメンバーと協働して、Rolldownというesbuldとrollupのいいとこ取りをして、まさに痒いところに手が届くツールを鋭意製作中のようです。今後ともフロントエンドビルドツールの動向は追っていければなと思います。今回は短いですが以上になります。また気が向いた時に加筆修正行っていこうかなと思います。