webpack ./entry.js bundle.js

webpack ./entry.jsbundle.js

</div>

在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中进行判断。

</div>