在前端刚诞生时，我们只能使用原生 JavaScript、CSS、HTML 方式编写页面代码，开发与生产环境代码基本一致，开发与运行效率都非常低；其次，页面的图片、代码、CSS等资源都只能通过 img、script、link 等标签插入页面中，我们需要设计好各个标签出现的位置、顺序，才能确保程序按我们的想法运行，这也会占用我们非常多的精力与注意力。
直到 2009 年 Node 与 RequireJS 的出现，让我们可以在代码被浏览器运行起来之前，有机会做一些预处理工作，后来诞生了许多效率工具，诸如 Babel、TypeScript、Less、Sass 等，它们影响甚至是颠覆我们编写 JavaScript、CSS、HTML 方式。
这些工程化工具能弥补浏览器、语言、规范本身的设计缺陷，让我们不需要再关注一些低效的技术细节，可以将更多注意力放在业务代码上，以更高效的方式编写出越来越复杂、庞大的 Web 应用。
打包工具的出现
在 Webpack 之前社区已经有了许多模块打包器，例如 Gulp、Grunt、RequireJS 等，但它们基本都是一种特化处理逻辑，并不能做到一键式打包各种类型文件，一份配置处理所有的信息。
而 Webpack 将所有文件类型都统一看做 Module，以相同的加载、解析、依赖管理、优化、合并流程实现打包，并借助 Lodaer、Plugin 两种开放接口让大家可以自由组合文件处理逻辑，可以兼容后续新诞生的各种文件类型。
Webpack 极强的开放性，让它得以成为前端工程化环境的容器，我们可以随时往 Webpack 项目中加入诸如 TypeScript、Babel、Sass、Jest 等工具与框架，获取对应的工程能力，完善我们的项目工程，提高我们项目的工程开发效率、质量、性能。
Webpack 的应用场景覆盖了 Web 应用、小程序、微前端、SSR、SSG、桌面应用程序、NPM 包等应用场景。
Webpack 也有许多工程方案：
- 基于 Module Federtaion 的微前端方案
- 基于 webpack-dev-sever 的 Hot Module Replacement
- 基于 Terser、Tree-shaking、SplitChunks 等工具的 JavaScript 代码压缩、优化、混淆方案
- 基于 lazyCompilation 的延迟编译功能
- 有利于提升应用性能的异步模块加载能力
- 有利于提升构建性能的持久化缓存能力
- 内置 JavaScript、JSON、二进制资源解析、生产能力
如何高效的掌握 Webpack
Webpack 的复杂程度远超想象：上百种内置配置项，七万多行代码，以及数不清的开源组件，设计的知识点多、杂、深，已经不能仅仅停留在单一构建工具层面，而是需要扩展开来学习一整套工程化思维与方法论。
我们想掌握好 Webpack 只能通过由浅入深、循序渐进、有章法有体系地学，不然就会有学东忘西的无奈感。我们可以通过以下四步来展开我们的学习路径：
- 上手实践各种场景下的构建配置方法，捋清楚最基本的使用规则
通过各种应用场景摸清使用规律，结构化地理解各基础配置项与常见组件的用法，毕竟 Webpack 内置的配置项就有上百种，且有许多配置规则，光通过阅读很难将各种配置理解清楚。
- 初步理解底层构建流程，学会分析性能卡点并据此做出正确性能优化
- 深入 Webpack 扩展规则，理解 Loader 与 Plugin 能做什么，怎么做
实际上，Webpack 主体只是实现了最核心的构建工具流与 Loader、Plugin 架构，大部分具体功能都是通过具体 Plugin 与 Loader 实现的，当我们理解这两者能做什么、怎么做时，我们就能更深层次理解 Webpack 的构建过程；也能在遇到疑难杂症时迅速定位到问题位置，甚至我们可以快速根据需求定制出我们需要的一套 Loader 和 Plugin 组合。
- 深挖源码，理解 Webpack 底层工作原理，加强应用与扩展能力
通过理解源码，我们可以理解 Webpack 的整个运行流程，从启动构建、递归编译模板代码、代码优化，到输出打包文件。当我们理解了整个流程后，我们才能更深入理解各个配置项到底作用在哪个步骤、哪些步骤容易造成性能卡点，我们要怎么优化、各个 Hook 到底在什么时间点触发、如何触发等。
