Sprocketsとwebpackerの違いです。
もし、app/assets/javascripts
の配下にJavaScriptが置いてある場合は、Sprocketsですので//= require ...
や//= require_tree .
の記述を使って下さい。
もし、app/javascript
の配下にJavaScriptが置いてある場合は、webpackerですので、require(...)
やimport ...
を使って下さい。この場合は、webpackerが利用するwebpackのドキュメントを参考にして下さい。import文はES2015+の構文ですので、MDNのJavaScriptのドキュメントも参考になります。
今日のコラム:JavaScriptのモジュール実装の歴史(Rails編)
もともとJavaScriptにはモジュールやライブラリという概念はありませんでした。ブラウザで複数のJavaScriptを指定した場合、それらは単に結合され、一つのJavaScriptのように動作します。JavaScriptの中で別のJavaScriptを呼び出すと言ったこともできなかったのです。つまり、複数のJavaScriptにわかれて記述する場合、HTML上に一つ一つscriptタグで指定していく必要があったと言うことです。順番も依存関係を考慮しなければなりませんし、競合した場合の解決方法も容易ではありません。
それではあまりにも不便なため、Sprocketsというものが開発されました。JavaScriptとしてはただのコメントですが、特殊なコメントを書くことで、他のJavaScriptをその部分に自動的に埋め込むようにしたのです。そのJavaScriptが依存しているものだけを書けば済みますし、それぞれのJavaScriptについてはIIFEにしておけば、競合も防げます。
また、JavaScript単独でもモジュールやライブラリを扱いたいと思う人は多くいました。Sprocketsとは別でCommonJS(require
を使う方法)やAMD等の手法が作られました。Node.jsが採用したとあって、CommonJSが主流になっていきました。
ブラウザ環境でのCommonJSは他のJavaScriptを動的に読み込むのではなく、Sprocketsのように予め複数のJavaScriptを結合して一つのファイルにするというものです(Node.js環境では動的に読み込みます)。その結合するツールとしてBrowserify、webpack、Rollup等が作られました。その中でも、webpackはJavaScriptだけではなくCSSや画像なども総合して扱えると言うこともあって、人気が出ました。
やがて、ES2015がリリースされ、JavaScriptの正式なモジュールの読み込み方法としてimport文が作られました。初めはやや混乱していましたが、import文はCommonJSにやや近い作りであったため、import文をCommonJSに変換できるようになりました(Babelを使用)。その時点でimport文が使えていたのですが、メインJavaScriptから使用される必要なコードだけを取り込むことを実装するために、webpack自体がimport文をサポートするようになりました。
時は経って、Railsの話です。ES2015リリース以降、JavaScript界隈はJavaScriptだけで動作するモジュールのエコシステムが発展し、多くの開発者もそれを使うようになりました。このとき、RailsのSprocketsはやや時代遅れなシステムになってしまっていたのです。そこで、Railsの開発者はwebpackを使ってJavaScriptを管理できるようにしました。そうして開発されたのがwebpackerで、Rails 5.1から使用できるようになりました。Rails 6からはJavaScriptのデフォルトをwebpackerに変更し、新規作成した場合は、Sprocketsは作らずに、webpackerのファイルのみ作られるようにしました。
ということで、新規アプリケーションでSprocketsの書き方をすることは今後ほとんどないと思います。import文の書き方はES2015+そのものですので、ES2015+を学んでいくと良いでしょう。
明日のコラム:ブラウザがネイティブにモジュールを扱う時代へ…(妄想編)
将来的にはwebpackもいらなくなると私は思っています。最新のモダンブラウザはモジュールベースのJavaScriptに対応しており、ES2015+構文のimport文をネイティブに取り扱えるからです。もはや、メイン処理のJavaScriptのライブラリのJavaScriptを一緒にしておく必要などありません。むしろ、ライブラリを独立して動的に読み込ませるのであれば、別々のメイン処理が書かれたJavaScriptを設置する場合、容量や転送量(同じライブラリならキャッシュされる)も削減されます。公開されたライブラリならCDNを使っても良いでしょう。
そんな時代が来たとき、webpackですら無用の長物になるような気がします。まぁ、先のことはわかりませんが。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2020/02/23 02:23