Webpackのloaderを理解します。
Webpackの途中結果をファイルにキャッシュするcache-loaderの中身を見ながら自分の手で再構成します。
環境
npm init
mkdir src example
としてexapmleの方にwebpack.config.jsを配置してどしどし実行。src配下にはloaderとなるjsを配置します。
webpack.config.jsのresolveLoadersにsrcのディレクトリを記述します。
実行する
単純にwebpackを実行すると、loadersファイルが実行されます。
デバッグする
実行コマンドを
node --inspect-brk node_modules/webpack/bin/webpack.js
とすればchromeのインスペクタパネルでデバッグできます。
How to write a loaderを読む
詳しくは公式ドキュメントを読むのが一番いいですが、exportsした関数にソースコードがstringとして渡ってくるようです。
https://github.com/webpack/docs/wiki/how-to-write-a-loader
Cache loaderの中身を理解する
Webpackのビルドはメモリ上のキャッシュを持つことで起動後の２回目以降のビルドを差分だけ行うことができます。
起動時にfileに書いておいたキャッシュを用いることで最初のビルドの高速化を図ろうというのがこのプラグインです。
pitching loaderについて
普段webpackのloaderは右から先に呼ばれます。
例えば
module: {
rules: [
{
test: /\.js$/,
use: [
'bar', 'foo'
]
}
]
}
上記のようなjsonの設定の場合fooから先に呼ばれるのですが、pitch関数はloaderが呼ばれる前に左から右に呼ばれます。
詳細は公式に
https://github.com/webpack/docs/wiki/loaders#pitching-loader
pitch関数内でreturn もしくは非同期の場合はthis.asyncをに第一引数をnullとして実行することでloaderの処理を飛ばすことができます。
Cache loaderの処理のオーバーヘッド
モジュール毎にファイルを生成したりファイルを読み込んだりしています。
Note that there is an overhead for saving the reading and saving the cache file, so only use this loader to cache expensive loaders.
Githubにもこう書いてる通りファイルIO部分のオーバヘッドが大きいのでしょう。。
ということでモジュール毎のキャッシュファイルから、一つのどでかいjsonファイルにキャッシュを詰め込むようにしたが効果がなかったどころかだいぶ遅くなってしまいました。。。
最適化は難しい