昔のプロジェクトで使われていた Closure Library を Webpack を使って楽に開発できないかと思うきっかけがあり、サンプルプロジェクトを使って Hot Module Replacement までやってみました。
サンプルプロジェクトはこちら
状況
元のプロジェクトとしては https://developers.google.com/closure/library/docs/tutorial を利用しています。
ノートを追加するボタンを追加した main
を ‘src/js/main.js’ に切り出し、 HMR イベント発生時のコードを ‘src/js/hmr-append.js’ に追加しています。
さらに、 SCSS で記述したスタイルも ‘src/scss/style.scss’ として追加しています。
Closure Compiler によるコンパイル処理は、 closure-builder で簡単にやってしまいます。
この Node パッケージは、 Closure Library も内包しているため、今回はこの中のファイルを参照するようビルド設定をしています。
(ただし、インストールスクリプトが走るとかなりの時間がかかるため、 google-closure-library の Node パッケージ内にある ‘compiler.jar’ と google-closure-library パッケージに付属している ‘closurebuilder.py’ を使い、自分で処理を組んだほうが楽かもしれません。)
さて、まずは Closure Compiler によるコンパイル処理をとりあえず構成したいと思います。
closure-builder の説明には ‘The Google Closure library will be included automatically if needed.’ とありますので、それについて今回は何も手を加える必要はありません。
ファイル名以外は何も考えることなく設定します。( なぜか sourceMap が上手く動いてくれません。 )
1 | const closureBuilder = require('closure-builder'); |
node build.js
などで実行すると、少しの時間が経過した後に ‘demo/bundle.js’ が生成物として出力されるはずです。
当然、これを html から呼び出せば、依存するスクリプトをすべて明示したのと同じように呼び出せます。
ただし、毎回コンパイルしているのでは開発時は待ち時間が長くなってしまうため、上述したように依存するスクリプトを全て呼び出すようにして開発していきます。
<!-- dev --> |
ただし、これ開発時とリリース時に切り替える必要があり面倒臭く、新しくファイルを追加するたびにタグを加えなければなりません。
今回は、 Webpack を使ってこの問題を解決し、さらに Hot Module Replacement も実現します。
Webpack 導入
Live Reload まで
さて、ここで Webpack を適応しようとしても、 Closure スクリプトの多くは goog.provide
と goog.require
による依存解決を行っているため、そのままでは上手くまとめられません。
うれしいことに、すでに closure-loader というものが作られているので使ってしまいます。
リリース用では yarn build
では Closure Compiler の方で生成するとして、開発用として Webpack Dev Server を使う前提で設定します。
まずは自作スクリプトの依存解決をします。 https://github.com/mxmul/closure-loader/issues/28 が参考になります。
自作スクリプトでの goog.require
の参照先は、別の自作スクリプトか Closure Library のため、 path
オプションでそれを指定します。
26 | { |
0 | /* omit */ |
42 | { |
続いて、 Closure Library の依存解決をします。
当然ながら、 goog.require
の参照先は、 Closure Library 内で完結しているので、 path
オプションでそれを指定します。
59 | { |
最後に、 Closure Library の中で使われている ‘base.js’ に対する設定をします。(goog
以下の、 Closure Library のシステムを支える関数が含まれる。)
73 行目で 1つだけ “exclude” されている理由です。
75 | { |
105 | new webpack.ProvidePlugin({ |
「goog.require
からの呼び出しとグローバルでも呼び出しに対応した goog
変数を用意する」と解釈すれば多分大丈夫そうです。
( imports-loader, exports-loader, ProvidePlugin )
あとは mode
と entry
、 devServer
を指定して Webpack Dev Server を起動すれば、 Live Reload まではできるようになっているはずです。( HMR は未設定)
ここまでで、 <script>
タグ群の切り替えをしなければならない事態は解消され、スクリプト修正後も検知してリロードしてくれます。
HMR まで
今まではツールを使ってばかりいたので、勝手に HMR までやってくれると思っていましたが、実際には明示的に処理を書き込まなければなりません。
Closure Compiler の方で生成されるリリース版に処理が書き加えられるのが嫌だったので、 ‘webpack.config.dev.js’ L30-L41 のように外部ファイル化して読み込むようにしてみました。もしリリース版でも Webpack を使うのであれば、何らかの loader か plugin で消去してしまうのもいいでしょう。
この部分は実装する機能とデータの持ち方でかなり変わってくるので参考程度にしかなりませんが、載せておきます。
私見ですが、 Closure Library で作られたアプリケーションでは状態の保持場所がカプセル化して散らばっていると思うので、割り切ってスクリプトは Live Reload にとどめておくのも手だと思います。
モジュールをHMRに対応するための実装について - Qiita がとても参考になります。
1 | // I wish that were pure or idempotent... |
無理矢理にではありますが、 HMR 可能であることの明示とデータの受け渡し、要素の初期化を行っています。
‘webpack.config.dev.js’ L108, L112, L117 のように設定して Webpack Dev Server を起動すると、追加したノートもそのまま表示してくれるようになります。
スタイルも HMR 可能に
最後に SCSS も設定してしまいます。まずはページに適用する SCSS ファイルの大元を entry
に加えます。
13 | entry: { |
(※ js ファイル用の設定も含む。)
SCSS ファイルの取り込みにはお馴染みの sass-loader と css-loader を使います。
加えて、 <link>
タグで外部 CSS ファイルを読み込んでいるであろうことから、スタイルをまとめて生成してくれる mini-css-extract-plugin と、その状況で HMR を使うために css-hot-loader も使います。
82 | { |
109 | new MiniCssExtractPlugin('bundle.css') |
(※ entry
に指定したキー値になる。この行で ‘hoge.css’ と指定しても ‘bundle.css’ となって出力される。)
これでスタイルの HMR も完成しました。