Seiichi Yonezawa

Rails 6からWebpackerがJSのコンパイラーとして採用される予定

昨日思いつきでmicroというソフトウェアを公開しました。 READMEには記述していませんが、特徴としてはRails 5で作っていることと、Webpackerを採用している部分です。 この投稿を書いていた頃はもうWebpackerは使わないと思いましたが、一年も経つと人もソフトウェアも変わるものです。

むしろWebpackerは今後きっと避けては通れないものになるだろうというわけで、今回は以下のGitHub Issueを抄訳していきます。 誤訳箇所等もあるかもしれませんので、引用とあわせて記載します。


https://github.com/rails/rails/pull/33079

Rails 6から変わること

まずは一番最初より:

Webpacker gem is installed by default and webpacker:install is run by the Rails application generator.

Webpacker gemはRailsのインストールコマンドで標準でwebpacker:installが実行されてインストールされるようになる。

Action Cable channel generators will create ES6 stubs rather than use CoffeeScript

Action CableのchannelはCoffeeからES6のスタブとして生成されるようになる。

Active Storage, Action Cable, Turbolinks, and Rails-UJS is loaded by a new application.js pack in app/javascript by default (unless any of the frameworks have been opted out).

Active Storage、Action Cable、TurbolinksとRails-UJSはapp/assets/javascriptsではなくapp/javascript/packにあるapplication.jsから生成されるようになる(個別にskipが指定された場合はこの限りではない)

Active Storage, Action Cable, Turbolinks, and Rails-UJS npm modules are automatically listed as dependencies in the default package.json.

Active Storage、Action Cable、TurbolinksとRails-UJSはnpmモジュールとして自動的にpackage.jsonに追加される。

All the JavaScript-related auxiliaries for Sprockets, like compression and uglifying, is no longer configured or included by default.

ファイル圧縮やUglifyなどSprocketsで使われるJavaScript関連のファイルは含まれなくなる。

No JavaScript stubs will be created by default when using the scaffold generators any more.

今まで標準でGeneratorから作られていたJavaScriptのスタブは今後生成されなくなる。

app/javascriptに関して

any reason to keep the javascript folder name in singular? why not following the pattern of plural name like controllers, models and views?

質問: javascriptのディレクトリがcontrollersやmodelsのように複数形ではなく単数形である理由は?

Because JavaScript is a language, not a classification of a domain type, like controllers or views or models. JavaScript has all those things. Saying "JavaScripts" imply that it's a collection of isolated, independent files, when it's not. It's the part of the application written in JavaScript.

回答: JavaScriptは言語であり、単にcontrollersやmodelsのようにドメインタイプのクラス名ではないからです。 「JavaScript」はこれらすべての意味を包括しています。 「JavaScripts」では分離されたコレクションや独立したファイルの集合のことだけを指してしまいます。 これはJavaScirptで書かれたアプリケーションの一部が保存されているという意味です。

sprocketsに関して

that means that sprockets will no longer be a dependency on Rails?

質問: sprocketsは今後Railsの依存関係に含まれなくなるのでしょうか。

No, Sprockets is still to be used for SCSS (and other CSS processors) as well as copying all other static assets.

回答: いいえ。SprocketsはこれからもSCSS(また他のCSSプロセッサ)や静的なファイルを管理する目的で使用されます。

(訳注: この決定に関しては否定的な反応が多い模様)

app/javascriptをapp/assetsに

My javascripts folder already has the images, js, packs, stylesheets folders inside. Would be nice to use the old assets folder instead of the current javascripts to hold all assets.

提案: 私のjavascriptsフォルダにはimages、js、packs、stylesheetsのフォルダに分かれています。app/javascriptからapp/assetsに置き換えるのはどうでしょうか。

This is the turning point when we can have that default path in assets and all generators and other packages point to that.

提案: 現在(Rails 6がリリースされる前)はアセット生成や他のパッケージを決められる絶好のはターニングポイントであると言えます。

Again, making it the rails way (and the consistent way) of keeping everything (js, images, css, etc.) in the assets folder and giving the developer the choice of using Webpack or sprockets for his CSS. It seems as the perfect setup.

提案: 繰り返しますが、Rails流ではWebpackかSprocketsかを選んですべて(js、画像、CSSなど)のファイルをassetsフォルダに保存するのが好ましいと思えます。

Keep supporting both sprockets and webpacker seems a bad idea: how do I explain to new developers that javascripts are managed by webpacker and stylesheets by sprockets? Seems a bit crazy to me. I would rather make a cut, take a clear decision, and switch to webpacker completely, rename the javascripts folder to webpacker (not assets to simplify migration process) and have the courage to embrace webpack 100%.

補足: SprocketsとWebpackerを共存させるのはよくないアイデアに思えます。 新しく加わった開発者にWebpackerとSprocketsをどのように管理するか伝えればよいでしょうか。 私はむしろ思い切ってSprocketsを切り捨ててWebpackerに完全に移行するべきだと思います(app/assetsは移行する必要があるため)。

(訳注: sprocketsに関してのDHHに対するコメントかもしれません)

If you can't explain to developers that JavaScript is managed by one process and stylesheets by another, I think maybe you're moving too fast in your educational program with these developers. Understanding that JavaScript is separate from stylesheets seems like a pretty fundamental thing to start with before diving into full application development.

回答: もし開発者にJavaScriptとStylesheetをそれぞれ別に管理する方法が難しく説明しきれないならば、それは開発者に対する教育プログラムが十分ではないと思います。 JavaScriptがStylesheetと分けて管理することを理解するのはフロントとバックエンドのアプリケーションの開発に対して基本的な部分であると思えます。

But you're also free to change your curriculum to focus on Webpacker. There is support for Webpacker handling other assets in addition to JavaScript, but it's not going to be the default in Rails 6.

回答: もちろんWebpackerを重点においたカリキュラムに変更するのは自由です。 WebpackerはJavaScriptを管理する方法のひとつに過ぎません。 しかし、それがRails 6ではデフォルトになるというだけの話です。

Sprocketは古い

sprockets are unmaintained at least for a year # sprocketsは1年以上更新されていない
sass unmaintained  # sassは更新されていない
sassc unmaintained # sassは更新されていない

but sprockets is still a hard runtime dependency in rails, I think it should be optional.

意見: Sprocketsは依然としてrailsの重要な箇所として含まれています。 (Webpacker移行は)オプションのままであるべきです。

My concern is that migration of an existing app from sprockets to full stack webpacker isn't easy, it requires many, many changes. It may even discourage people from upgrading if it would be the only option. We also decided to move to webpacker because working with sprockets was really painful. I support the idea that it should be default even for sass/css.

意見: 私の懸念はSprocketsからWebpackerへの移行が簡単ではないという点です。 移行には非常にたくさんの変更を要します。 これはアップグレードを遅らせる要因になりかねません。 私達はSprocketsからWebpackerへの移行を決定しましたが、非常に大変です。

Who said that? We just released a new 4.0 beta 28 days ago.

メンテナ: (sprocketsが1年以上更新されていないに対して)Sprockets 4.0ベータは1ヶ月前(訳注:7/18/2018当時)にリリース済みです。

感想

Ruby on Railsというフレームワークは大胆な変更をしても、こうして受け入れ続けられてきました。 これがあくまでrails newで生成されるアプリケーションに対する話であって、既存のアプリケーションに対する強制ではありません。 Redmineのように最新のRailsに対応しつつもSprocketsやWebpackerを使わないアプリケーションも存在するのが驚きです。

私は最初このIssueのタイトルを目にしたときにネガティブな想像をしましたが、今はむしろRails 6がここまで進んでいることに対して安心しました。 当初この投稿のタイトルもSprocketsに対することを書こうと思っていました。 高度化していくJavaScriptを扱うのは簡単ではありませんが、今後WebpackerがRailsにおいて重要な役割を果たしていくことになるのは間違いなさそうです。

投稿一覧