三、配置化是银弹吗？
在日常业务中，特别是大公司的一些运营性质的业务里，我们常常会看到 “某某业务已经实现完全配置化” 这样的字眼，在这个语境里，配置化代表了低维护成本、高灵活性、高封装性。
在技术的世界里，配置化也同样是个好东西，很多工具都会宣称自己是完全配置化的，只要你的项目里加入一个配置文件，那么这个工具就可以帮你做很多很多的事情，babel、eslint、stylelint，还有本文讨论的 webpack 都是如此。
所以配置化是不是就是所有工具进化的终点了呢？它是不是能解决所有的问题呢？
软件工程上有一句耳熟能详的话：“没有银弹”，指的是复杂的软件工程问题无法靠简单的答案来解决。在前端工程构建这个问题上，也同样不例外。
如何解决前端工程的构建？webpack 给出的答案是：通过 webpack loader plugin，让一切资源构建可配置。 这在它诞生的那个时代看来，是非常厉害的，一份简单的配置文件就帮你搞定了所有资源构建的问题。
但是当时间的推移，一个前端项目的构建变得越来越复杂，webpack 的配置也越来越多，维护起来越来越难，这个时候，也就慢慢诞生了诸如 create-react-app、vue-cli 这样的脚手架工具，在 webpack 的基础上进一步封装，来帮你自动生成 webpack 的配置。这个时候，webpack 更多地变成了一个“底层”工具，而这些脚手架才是你实际上的“构建工具”，或者说，这些脚手架提供的配置，才是你真正的构建配置。
为什么会这样？
这个问题的根源在于，webpack 现在提供的配置的封装性已经不够了，它面对一个如今复杂得多的大型前端工程，仅有的配置已经没办法像几年前那样为我们屏蔽掉大部分的构建细节了，所以在它的基础上诞生了如此多的脚手架工具帮我们进一步封装复杂性。
所以我们现在可以回答这一段的标题了：配置化是解决复杂度的银弹吗？当然不是，因为配置会随着复杂度的提升，而也逐渐变得复杂，维护越来越难，直到超过某个临界值，就会需要在它的基础上进一步封装，产生新的配置化。
四、前端工程构建的未来
正如我在上一章所说的，随着复杂度的上升，需要不断地封装复杂性，以让维护配置的心智成本降到可以接受的程度。而在前端构建工具上，截止到趋势也正是如此：
- 前端的远古时代我们不需要构建，因为这时的前端项目还很简单，原始的 html/js/css 就足以应付需求，手工处理这些资源方便又快捷。
- 随着前端的复杂化，手工处理的效率越来越低，grunt、gulp 这样的自动化工具就诞生了，它们屏蔽掉了很多资源处理的细节问题，让资源的处理可以自动完成。
- 随着构建流程越来越多、资源种类越来越多、ECMAScript 的语言特性愈加复杂、开始区分开发/测试/生产环境等等因素，gulpfile/grunt 这样的工具已经不能满足我们的需求，我们需要的是一整套完整的配置化的构建方案，而 webpack 就是这样一种方案。
- 随着 webpack 配置越来越复杂，维护成本也越来越高，于是诞生了很多脚手架工具，帮你生成 webpack 的配置，封装起 webpack 的复杂性。
那么未来的下一代前端构建工具是怎样的呢？
现在广泛使用的这些脚手架工具，终究依赖的是 webpack，我们实际上需要的是集成度更高、封装性更高（甚至零配置）的构建工具。更详细地说，下一代前端构建工具，必然会有下面的某些特性：
- 内置的功能更多，比如自带 babel、dev-server、HMR、sourceMap 等等功能；
- 配置更少，甚至零配置；
- 更低成本区分开发、测试、生产环境；
- 性能更好，整合冗长的构建流程，支持多核 CPU 等；
- 对于新型模块的支持：异步模块、WebAssembly 模块等。
事实上，这也就是部分 webpack 4.0 将会有的新特性，以及前段时间看到的 parcel 也具有其中的某些特点（虽然它现在看起来还很不成熟）。未来这样的构建工具只会越来越多。
总结
这篇文章很久之前就在构思了，只是近期在工作上集中遇到了很多 webpack 的坑，让我彻底有动力来吐槽一下它的种种不是。
webpack 为什么这么难用？本文给出的答案浓缩起来就是两点：
- 文档不完善，导致使用者和开发者遇到问题都很难下手；
- 项目需要使用的插件数量太多，且面向配置，导致维护成本指数级上升。
这些问题未来会有改善吗？当然。其实，这篇文章其实有标题党的嫌疑，更准确的标题应该是：
《现在的 webpack 为什么这么难用？》
因为这篇文章里提到的问题，都会在 webpack 4.0 中得到改善。
