Webpack

在前端模块化尚未流行的年代里，每个HTML文件的尾部都会挂载很多的 script 标签来载入JavaScript代码，各个文件之间的依赖异常混乱，项目的可维护性随着代码的增加而迅速降低，整个应用的开发流程中也尚未有专门的编译流程。后来出现了以Grunt/Gulp为代表的所谓的Task Runner。虽然类似于Gulp这样的Task Runner也能添加很多的预处理器或者转换器，但是本质上它仍然需要指定元输入。而Webpack最早的动因即是希望能够让开发工具自己去处理模块依赖问题，开发者不需要再为每一个任务去指定输入输出：

综上所述，Webpack具有如下优点：

• 代码拆分：Webpack有两种组织模块依赖的方式，同步和异步。异步依赖作为分割点，形成一个新的块。在优化了依赖树后，每一个异步区块都作为一个文件被打包。
• Loader：Webpack本身只能处理原生的JavaScript模块，但是loader转换器可以将各种类型的资源转换成JavaScript模块。这样，任何资源都可以成为Webpack可以处理的模块。
• 智能解析：Webpack有一个智能解析器，几乎可以处理任何第三方库，无论它们的模块形式是CommonJS、AMD还是普通的JS文件。甚至在加载依赖的时候，允许使用动态表达式 require("./templates/" + name + ".jade")。
• 插件系统：Webpack还有一个功能丰富的插件系统。大多数内容功能都是基于这个插件系统运行的，还可以开发和使用开源的Webpack插件，来满足各式各样的需求。
• 快速运行：Webpack使用异步IO和多级缓存提高运行效率，这使得Webpack能够以令人难以置信的速度快速增量编译。Webpack是笔者见过的最强大的模块管理器与编译工具，他不仅仅同时支持CMD与AMD模式，也能实时编译JSX、ES6等语法，还能将CSS、图片等资源文件都进行打包。

基础配置

作为著名的打包工具，Webpack允许我们指定项目的入口地址，然后自动将用到的资源，经由Loader与Plugin的转换，打包到包体文件中在介绍具体的配置方案之前笔者想先概述下该配置文件的设计的目标，或者说是笔者认为一个前端编译环境应该达成的特性，这样以后即使Webpack被淘汰了也可以利用其他的譬如JSPM之类的来完成类似的工作。

配置级需求：

• 单一的配置文件：很多项目里面是把开发环境与生产环境写了两个配置文件，可能笔者比较懒吧，不喜欢这么做，因此笔者的第一个特性就是单一的配置文件，然后通过npm封装不同的编译命令传入环境变量，然后在配置文件中根据不同的环境变量进行动态响应。另外，要保证一个Boilerplate能够在最小修改的情况下应用到其他项目。
• 多应用入口支持：无论是单页应用还是多页应用，在Webpack中往往会把一个html文件作为一个入口。笔者在进行项目开发时，往往会需要面对多个入口，即多个HTML文件，然后这个HTML文件加载不同的JS或者CSS文件。譬如登录页面与主界面，往往可以视作两个不同的入口。Webpack原生提倡的配置方案是面向过程的，而笔者在这里是面向应用方式的封装配置。

开发与构建级需求：

• 调试时热加载：这个特性毋庸多言，不过热加载因为走得是中间服务器，同时只能支持监听一个项目，因此需要在多应用配置的情况下加上一个参数，即指定当前调试的应用。
• 自动化的Polyfill：这个是Webpack自带的一个特性吧，不过笔者就加以整合，主要是实现了对于ES6、React、CSS(Flexbox)等等的自动Polyfill。
• 资源文件的自动管理：这部分主要指从模板自动生成目标HTML文件、自动处理图片/字体等资源文件以及自动提取出CSS文件等。
• 文件分割与异步加载：可以将多个应用中的公共文件，譬如都引用了React类库的话，可以将这部分文件提取出来，这样前端可以减少一定的数据传输。另外的话还需要支持组件的异步加载，譬如用了React Router，那需要支持组件在需要时再加载。