前端工程化的意义（前端工程化概念）

先上我的答案：Webpack 作为前端工程化环节最为流行的工具，作为深刻改变了前端开发模式的技术，自然是有必要学的。

但是，Webpack 体系如今并不是一个简单的 bundler，更是一个弘大的生态，纷杂的插件点铸成了一张信息密度极高的图谱；同时，如今前端开发含焦量超标，Frontend fatigué 叫苦不迭。因此，我们应该学习哪部分，怎样进行学习，学习了解后如何更进一步挖掘前端工程发展趋势？—— 这才是更为关键的话题。

就像题主所提，「面试当中有时候会问到 Webpack 相关的配置」是我首先要强烈批判的点，也是 Webpack 学习雷区，「熟背 Webpack」并不是健康的学习导向。作为面试官，我看到了太多「熟练使用并了解 Webpack，对前端工程化有相关积累」===「我能记清楚很多 Webpack 配置项，甚至默写出 Webpack 配置模版代码，迅速启动项目基建」。当知识技术成为应试八股文，人才招聘就沦为「面试造火箭，工作拧螺丝」的「逢场作戏」。

这样的学习导向和学习方式，使得前端学习者或面试求职者为了破局，焦虑地渐渐成为「短期速成知识」的收集者和背诵者，我们以为收藏的是知识，其实收藏的是八股文，我们以为掌握了知识，其实只是囤积了一堆配置项。

那我们应该学习哪些 Webpack 知识呢？

我在 回答中，从

• Code Splitting
• Hashing
• Importing Modules
• Non-JavaScript Resources
• Output Module Formats
• Transformations

六个方面介绍了工程化工具的关注点。

Webpack 支持能力较高，当然也是通过「各种配置」来完成。

因此，通过 Webpack 配置，我们应该学习的是其背后工程化需求和相应能力。

仅以以上 Hashing 一项来说。Hashing，即对打包资源进行版本信息映射。这个话题背后的重要技术点是最合理地利用缓存机制。我们知道有效的缓存策略将直接影响页面加载表现，决定用户体验。那么对于 Webpack，为了实现更合理的 hash 机制，就需要分析各种打包资源，导出模块间依赖关系，依据依赖关系上下文决定产出包的。因为一个资源的变动，将会引起其依赖下游的关联资源变动，因此工程工具进行打包的前提就是对各个模块依赖关系进行分析，并根据依赖关系，支持开发者自行定义哈希策略。

比如，Webpack 提供的不同类型 hash 的区别：hash / chunkhash / contenthash，这三种 hashing 策略你都了解吗？为什么有这三种策略的设计呢？这也许是更值得学习的内容。

其实虽然 Webpack 看上去无所不能，但从其本质上来说，Webpack 实质就是一个「前端模块打包器」。前端模块打包器做的事情很简单：它帮助开发者将 JavaScript 模块（各种类型的模块化规范）打包为一个或多个 JavaScript 脚本文件。

其最核心的技术原理上自然是基于 AST 的编译构建流程。如下图，

如果你不是计算机科班出身，那么通过实现一个打包器，将是深入了解 Webpack 核心和计算机科学大门的有效途径。打包过程主要分为两步：依赖解析（Dependency Resolution）和代码打包（Bundling），从步骤上，看起来并不困难：

1. 读取入口文件（比如 entry.js）

2. 基于 AST 分析入口文件，并产出依赖列表

3. 使用 Babel 将相关模块编译降级

4. 对每个依赖模块产出一个唯一的 ID，方便后续读取模块相关内容

5. 将每个依赖以及经过 Babel 编译过后的内容，存储在一个对象中进行维护

6. 遍历上一步中的对象，构建出一个依赖图（Dependency Graph）

7. 将各模块内容 bundle 产出

当然，学习 Webpack 并不是要求人均手写打包器，而是希望你更了解前端工程流程。除了日常 npm install, npm run dev, npm run build，当你在面对 terminal 上红色的 Error 时，也能更加从容地解决处理。

Webpack 实现工程化方方面面的功能，自然不是 all in one codebase 实现的。从 Webpack 的设计理念和实现原理中，我们能学习到一种面向功能进行拆分的可扩展性架构。

Webpack 工作流程简单如下图，

Webpack 就像一条生产线，要经过一系列处理流程后才能将源文件转换成输出结果。这条生产线上的每个处理流程的职责都是单一的，多个流程之间有存在依赖关系。插件就像是一个插入到生产线中的一个功能，在特定的时机对生产线上的资源做处理。

Webpack 通过 Tapable —— 这个独立的包来组织这条复杂的生产线。通过事件发布订阅机制，插件只需要监听它所关心的事件，就能加入到这条生产线中，去改变生产线的运作。

当然，在 Webpack 生态体系上，也少不了 loader，Webpack loader 和 plugin 就像 webpack 的双子星，有着相同之处，但是分工却很明晰。

• loader 其实就是一个转换器，执行单纯的文件转换操作
• plugin 是一个扩展器，它丰富了 webpack 本身

当然，插件化可扩展架构或者微内核架构，对插件管理 -> 插件连接 -> 插件通信细节环节也有着精确的管控，这些在 Webpack 的设计实现上都有明确体现。这里我们不单独展开。

随着前端技术体系的发展，Webpack 也当然不时刻代表着第一先进性。如今，bundleless 技术理念早已成熟。这里想表达的是学习 Webpack，也能帮我们进行技术前瞻。

如下图，

以 Vite 为例，

Vite，一个基于浏览器原生 ES imports 的开发服务器。利用浏览器去解析 imports，在服务器端按需编译返回，完全跳过了打包这个概念，服务器随起随用。同时不仅有 Vue 文件支持，还搞定了热更新，而且热更新的速度不会随着模块增多而变慢。针对生产环境则可以把同一份代码用 Rollup 打包。虽然现在还比较粗糙，但这个方向我觉得是有潜力的，做得好可以彻底解决改一行代码等半天热更新的问题。

从这段话中我们能够提炼一些关键点：

• Vite 基于 ESM，因此实现了快速启动和即时模块热更新能力
• Vite 在服务端实现了按需编译

经验丰富的开发者通过上述介绍，似乎就能给出 Vite 的基本流程，甚至可以说得更直白一些：Vite 在开发环境下并没有打包和构建过程。

开发者在代码中写到的 ESM 导入语法会直接发送给服务器，而服务器也直接将 ESM 模块内容运行处理后，下发给浏览器。接着，现代浏览器通过解析 script module，对每一个 import 到的模块进行 HTTP 请求，服务器继续对这些 HTTP 请求进行处理并响应。

更多原理展开：

• Vite 利用浏览器原生支持 ESM 这一特性，省略了对模块的打包，也就不需要生成 bundle，因此初次启动更快，HMR 特性友好。
• Vite 开发模式下，通过启动 koa 服务器，在服务端完成模块的改写（比如单文件的解析编译等）和请求处理，实现真正的按需编译。
• Vite Server 所有逻辑基本都依赖中间件实现。这些中间件，拦截请求之后，完成了如下内容：
• 处理 ESM 语法，比如将业务代码中的 import 第三方依赖路径转为浏览器可识别的依赖路径
• 对 .ts、.vue 等文件进行即时编译
• 对 Sass/Less 的需要预编译的模块进行编译
• 和浏览器端建立 socket 连接，实现 HMR

前端技术是不断迭代发展的，对于 Webpack 的学习，我们当然不鼓励刻舟求剑般的死板处之，而更应该倡导触类旁通，做到技术前瞻。

Webpack 的学习角度还有更多（如通过 Webpack 了解性能优化方案等），我想，在这个信息爆炸的时代，信息量呈几何级数增长，知识似乎唾手可得。那么该学什么，到底该怎么学，学完之后又该做什么？大部分人都会在知识面前焦虑、迷茫。

我绝不相信一本「武功秘籍」就能让每个人一路打怪升级，一步登天。更何况每个人的诉求和成长路线都不相同，所以「前端有必要学习 Webpack 吗」也永远不会有唯一的答案，而开篇的「自然是有必要学的」也只出自我的成长曲线。

当下时间节点，俄乌依旧动荡不安，国际时局大国博弈；市场上，资本依然停留在寒冬；社会上，疫情挑战依然严峻、乱象横生。希望一切就像阿尔贝•加缪在《鼠疫》中所说的那样：

「春天的脚步正从所有偏远的区域向疫区走来。成千上万朵玫瑰依旧枯萎在市场和街道两旁花商的篮子里，但空气中充溢着它们的香气。」

书中另外一句话也让我印象深刻：

「对未来真正的慷慨，是把一切献给现在」

愿每个人都能通过学习找到平静，愿社会安宁、世界和平。

Happy coding!