vite_ruby入れてみたけど、非常にDXが良い
— ころちゃん (@corocn) May 24, 2021
を見かけたので Vite 1 beta の頃に独自に Helper 書いて導入したものをリプレイスして v2 にしちゃおう作戦。
前提
- Vite を独自に導入済み。Webpack → Vite の migration で感動した！みたいな話はなし
- Vite 1 beta を vite_ruby x Vite 2 に migrate.
- Vite 1 beta を Ruby から利用してた際は Helper を独自実装していた
導入したのは vite_ruby 1.2.11
Vite 1 beta 利用時の課題
- Vite の dev は Ruby 側の development で使う分にはいいが Ruby 側の test で使うと初回のいろいろな解決が走って重い、build を使ったら使ったで実際に build が走ってやはり重い
- entry point が複数になる場合に vite.config.js を複数用意する必要があり、非常にダルい、というか現実のアプリだと entry point は複数になるでしょ
導入して良い点
- vite_ruby の導入は Vite の抱えていた entry point 周りの課題をきれいに解決してくれて助かる
- vite.config.js からの rollup の設定へどんどん深みにハマっていく必要がない
- autoBuild を利用すると上記の重さはかなり改善される
導入するなら考えた方が良い点
- Webpacker 同様 Helper を通して Ruby 側で asset 周りの reverse proxy を実現しているが、このおかげでもう WEBrick での開発は現実的でなくなる
- ES Modules は Webpack と違ってブラウザ上で直接 import が動いて HTTP connection が爆発する
- 同じく asset へのアクセスが大量に発生するので logger に工夫が必要かも
- Webpacker 同様 Helper に新しい名前空間を用意し、そっちの利用を強制してくるのでちゃんと従おう
特に HTTP connection が増えて WEBrick では耐えられなくなる点は大きくて、恐らく Puma を使うのが素直な解決策1だが、Rails のようにライブラリが充実している環境でない、例えば Sinatra や Hanami を利用する場合、 Puma を development 環境で使うのはちょっと扱いにくいので注意が必要。
余談：Ruby外のasset bundlerとRubyを組み合わせる方法と注意点と自分の考えていること
ここからは完全に脱線なので、一つの考え方として参考になるかも。ならないかも。
個人的には Ruby バックエンドや静的サイトジェネレータと Webpack などの asset bundler の組み合わせはそこそこ試してて、
- Ruby 側の Asset Helper の実装
- Ruby で reverse proxy の実装
- Node.js で reverse proxy の実装
を何通りかやっている。2
そのうえで上で書いた Vite 1 beta 利用時の独自 Helper ではあえて reverse proxy を使わない Helper を書いていた3んだけど、vite_ruby は Webpacker を模倣してしまったので Ruby 側の負荷が爆発する形になってしまっている。
Webpack は bundle 済みの asset を serve するので reverse proxy が Ruby 側にあってもよいかもしれないけど、ES Modules は bundle せずに HTTP に丸投げになるので、かなり動作が違う。ここは真似する必要なかったのではないか。
まぁ reverse proxy を Ruby 側に持たせることが一概に悪いこととは言えないんだけど、シンプルな、「Rails を使うほどではないよなぁという開発」の場合に Rails のエコシステムを前提にした「なんでも揃ってる感覚」でやるといろいろハマりが多いので、できればそれほど Ruby の得意なわけではない大量の HTTP の処理が Ruby に回ってくる設計にはしない方がいいんじゃないかと個人的には考えている。
もちろん「デキアイのツールをただ組み合わせて実現できる」ものでやる方がいろいろ端折れて早いのも事実なので、鉄板構成を見つけて鉄板構成だけで押すという姿勢も大事なんだけど、それぞれの得意なこと不得意なことは知っておくといいよ、とも思った。