原文: http://weblog.rubyonrails.org/2017/8/30/webpacker-3-0/
RailsとWebpackをいっしょに使うのを、この3つ目のWebpackerリリースで、さらに簡単にした。2つの大きな変更は、開発中に別のプロセスがもはや不要なことと、大部分の設定は、いまやWebpacker npm package内に置かれていることだ。だから、あなたのconfig/ディレクトリはきれいなままで、アップデートもより簡単だ。
開発およびテスト中、Webpackerにオンデマンドでコンパイルさせることで、別プロセスの必要性を排除した。このプロセスを高速化するためにいろいろやった結果、多くのアプリで、パフォーマンスは良好以上になることだろう。しかし、巨大なアプリの場合、もしくは、ライブリローディングやhot module replacementが好みならば、 bin/webpack-dev-serverを使い続けることができる。Webpackerは、このプロセスが走っていることを自動的に検出して、packをオンデマンドではなくそこから供給する。賢いね。
それから、Railsのconfig/ディレクトリに生成される設定ボイラープレートの総量を劇的に減らした。標準的はものはすべて、いまではWebpack npmモジュール内に置かれている。これは、アップグレードをとても簡単にする。さらに、デフォルトを好みに応じて上書きすることも依然として可能だ。だから、これはあらゆる面での大勝利なのだ。
くわえて、コンパイルと削除ロジックをすべてRakeタスクからはずして、Webpackerシングルトンインスタンス自身に入れた。これでWebpackerのセットアップを変更して使うのが簡単になる。たとえば、Yarnを使わなかったり、assets:precompileとは異なるデプロイ戦略を取るというようなことだ。
これは、Webpacker内部の大規模なリファクタリングに伴うものだ。消えたのは個々のシングルトンで、単一のトップレベルシングルトンに置き換えられた。これは、設定や、コンパイルなどのためのクラス群をただ集約する。
Webpacker 3.0は、Rails 6.0における「デフォルトでのWebpack」戦略がそうあるようなものを目指している。そこでは、アセットパイプラインは、画像、フォント、音源、そしてSASSを使ってコンパイルされたCSSなどのような静的アセットに注力するが、JavaScriptコンパイルゲームからは離脱する。我々は、最終的なアプローチをまだ決めてはいない、しかし、これが、次の大きなRailsリリースで、2つのものがJavaScript、スタイルシート、そして他のアセットの扱いをどのように分割するかについての、現在最良のアイデアだ。
まだ、Webpack、ES6風味のJavaScript、そして他すべてのモダンなクライアント側開発体験の進歩を試していないなら、Webpacker 3.0は、はじめるのに絶好の機会だ。Basecampでは、すでにプロダクションでこれを使っている。大きなJavaScriptクライアントサイドフレームワークは使ってないけどね。Turbolinks + Action Cable + Vanilla JSアプローチといっしょにも、うまく動作する。
そして、React,Vue,AngularまたはElmとRailsをいっしょに使うつもりなら、Webpackerがなにもかもをとても簡単にしてくれる。それらのフレームワークのためのHello Worldジェネレーター群さえも含むので、退屈なマニュアル設定をまったくしないでも、開発をはじめられる。
この新しいメジャーリリースには、たくさんの貢献者がいるが、とくにGaurav TiwariとJavan Makhmaliの大きく継続的な貢献に感謝したい。たのしんで!