也來說說webpack

webpack ./entry.js bundle.js

webpack ./entry.jsbundle.js

在CLI模式中，第一個參數是入口文件，第二個參數是輸出文件，并讀取當前cwd目錄下面的 webpack.config.js 配置，根據配置生成對應的bundle.js文件。

其用法與RequireJS里面的r.js命令極其相似。

快速上手

如果一個新業務，想做一下JS的模塊化管理，那么可以立即選擇webpack了。

如果一個老業務，曾經用了RequireJS或者SeaJS，那么也可以選擇切換webpack了。

如果想做一個庫\框架去為生態提供服務，也可以立即選擇webpack，他能自動配置最終生成的library.js文件支持AMD\CommonJS等模塊化方案。

用好配置里面的 resolve ，改造一下原有的Grunt\Gulp流程，即可使用webpack，業務代碼基本無需改造。

多種模塊化打包加載方案對比： http://webpack.github.io/docs/comparison.html 。

其實對于老業務而已，僅僅將JS的模塊化從RequireJS替換到webpack，其收益并不明顯，僅僅是最后生成的JS文件要小一些而已。

進階

如果單單從CLI模式中的提供的參數來看，webpack的能力也就到此為止了。但webpack的作者并非只想做一個AMD\CommonJS\ES6 Modules的協議實現。

webpack提供了一個Loader和Plugin的機制，讓社區通過提交自己的Loader和Plugin，大大拓展了webpack的應用場景。

別忘了，webpack的REPL可是完整的nodejs，也就是說Grunt、Gulp能做的事情，webpack也能做（只是能做，不代表webpack擅長做）。

同時，通過各種Loader和Plugin，webpack還能打包樣式、圖片等資源文件，并按需將這些資源文件inline到html中。

與babel的勾搭

建議es-2015就先別折騰了，webpack本身編譯速度，在我的MBP上面是50ms上下，但加入babel并使用es-2015語法轉換后，編譯耗時直接漲到700~800ms，這還僅僅是只有兩個js文件的demo。

在webpack的roadmap里面，看到有對ES6 Modules進行支持的計劃，我們還是靜等吧。

欠成熟的Loader和Plugin列表

其最富有想象力、最能拓展的Loader和Plugin，她們的列表是竟然是人工維護的一份Github Pages。相對于其他社區來說，這塊差了點。同時由于是手動維護的列表，其Loader和Plugin的質量，只能通過Github和npm中進行判斷。