作ったソースを統合して管理するツール grunt とか glup とかとの同系列のツールでより依存性管理ビルドに特化している。

これを考えないで理解を進めようとするとハマる。

webpack は依存性を解決するように実行順を調整して組み上げるツールではない。 依存性が解決して正しく動くであろうコードを生成するツールである。

つまりプログラマが書いたものが動くのではなく、webpack が作ったモノが動くのである。

何も設定しなくても動く。

その時は src/index.js というファイルを読みに行って、 dist/main.js というファイルが吐き出される。

webpack.config.js という名前で書かれることが多い設定ファイル。 基本的にココに JSON 的に設定を書いていくのだが、js ファイルなのでそのへんはいろいろ動的にできる。

webpack では module というオブジェクトにいろいろセットすることで組み上げていく

module.exports = {
    entry: './src/entry.js',
    output: {
        filename: 'output.js',
        path: './dist'
    }
};

この場合は、src/entry.js から入って、こいつが依存しているモジュールを次々に読み込んで、最終的に entry.js が実行される・・・というような output.js を生成する、ということになる。

$ npx webpack --config webpack.config.js

この出来上がった output.js をブラウザ側で script タグで読み込めば意図した通りに動く。

このように依存性があるファイルを require というメソッドで指定して変数で受ける

var hoge = require('./HogeModule');
hoge.piyo();

この例ではオブジェクトが戻ってきている想定だが、それが関数であったりとか、 クラス的関数であったりしてもよい。

それを使えばよい

逆にこの HogeModule の中では何が行われているかというと このようなコードが書かれていて、このコード中の使えるインターフェース部分を module.exports に突っ込んでいる。

module.exports = {
    piyo: function(){
    }
};

この突っ込んだ内容が require の戻りとなる。 JS 的にそういうのではなく webpack がそうなるようなソースを生成する。 これは JS のロジックではなく webpack の設定を書いているという意識。

混乱するのでまた書いておく。webpack が 各JSファイルを依存性を解決するように呼び出すのではなく、依存性を解決するような順番で動くように仕組まれた1つの js ファイルを生成するのである。