也来说说webpack

入门

webpack,官方定位是一个模块打包工具,基础命令极其简单

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