什么是前端工程化

曾经终败给现在 2022-11-15 05:54 190阅读 0赞

![fffca70a1a57d38fc3182a75755cf74c.png][]

来源：Lucas HC

https://www.zhihu.com/question/433854153/answer/1713597311

我认为，「什么是前端工程化」——这是一个很好的问题，但同时也是一个非常「务虚」的问题。

因为前端工程化是一个极度宽泛且宏大的概念，我们很难去下一个定义，也无法给出一个样例来解释。**我试图从工程（构建）工具对比和一个线上 bug 的处理来侧面说明。**

--------------------

## 工具篇 ##

提到工程化（构建）工具，作为经验丰富的前端开发者，相信你能列举出不同时代的代表：从 Browserify + Gulp 到 Parcel，从 Webpack 到 Rollup，甚至 @尤雨溪编写的 Vite，相信你也并不陌生。没错，前端发展到现在，工程化工具琳琅满目。但很多工具的实现和设计非常复杂，甚至出现了「面向 webpack 编程」的调侃。

ToolingReport 是由 Chrome core team 核心成员以及业内著名开发者打造的构建工具比对平台。这个平台对比了 Webpack v4、Rollup v2、Parcel v2、Browserify + Gulp 在不同维度下的表现，如下图所示：

![5fefb2117f0cbd072863beb04fdf7a91.png][]

测评通过的 test 得分只是一个方面，实际情况也和不同构建工具的设计目标有关。比如，Webpack 的构建主要依赖了插件和 loader，因此它的能力虽然强大，但配置信息较为烦琐。而 Parcel 的设计目标之一就是零配置，开箱即用，但是在功能的集成上相对有限。

但从工程化的角度出发，我们还是从上面的分数分析，来看看这些分数评测的维度。这些分数来自以下 6 个维度的评测：

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

![5cc8f2fc9ab0db608a513f74c2217f52.png][]

和工程化主题相关的是：这 6 个维度到底是什么，为什么它们能作为考量指标被选取为评测参考标准？下面我们逐一进行分析。

**Code Splitting，即代码分割。这意味着在构建打包时，能够将静态资源拆分，因此在页面加载时，实现最合理的按需加载策略**。

实际上，Code Splitting 是一个很深的话题。比如：不同模块间的代码分割机制能否支持不同的上下文环境（Web worker 环境等特殊上下文情况），如何实现对 Dynamic Import 语法特性的支持，应用配置多入口/单入口时是否支持重复模块的抽取并打包，代码模块间是否支持 Living Bindings（如果被依赖的 module 中的值发生了变化，则会映射到所有依赖该值的模块中）。

总之，Code Splitting **直接决定了前端的静态资源产出情况**，影响着项目应用的性能表现。是前端工程化这颗大树的一个分支。

**Hashing，即对打包资源进行版本信息映射**。这个话题背后的重要技术点是**最合理地利用缓存机制**。我们知道有效的缓存策略将直接影响页面加载表现，决定用户体验。那么对于前端工程化来说，为了实现更合理的 hash 机制，工具就需要分析各种打包资源，导出模块间依赖关系，依据依赖关系上下文决定产出包的哈希值。因为一个资源的变动，将会引起其依赖下游的关联资源变动，因此**工程工具进行打包的前提就是对各个模块依赖关系进行分析，并根据依赖关系，支持开发者自行定义哈希策略。**比如，Webpack 提供的不同类型 hash 的区别：hash/chunkhash/contenthash，这三种 hashing 策略你都了解吗？为什么有这三种策略的设计呢？具体我就不展开了。

**Output Module Formats**，工程输出的模块化方式也需要更加灵活，比如开发者可配置 ESM、CommonJS 等规范的构建内容导出。

**Transformations**，前端工程化离不开编译/转义过程。比如对 JavaScript 代码的压缩、对无用代码的删除（DCE）等。这里需要站在工程化视觉上注意的是，**我们在设计构建工具时，对于类似 JSX 的编译、.vue 文件的编译，不会内置到工具当中，而是利用 Babel 等社区能力，「无缝融合」到工程化流程里**。工程化工具只做分内的事情，其他扩展能力通过插件化机制来完成，显然是一个非常工程化的设计。

其他 **Importing Modules** 以及 **Non-JavaScript Resources** 我不多说了，虽然这是评测工程化工具的几个大方向，但每一个都是前端工程化的重要主题。

## 线上问题篇 ##

这一部分，让我们以一篇文章《[报告老板，我们的 H5 页面在 iOS 11 系统上白屏了！][H5 _ iOS 11]》分析，我先简单梳理和总结一下文章表达的内容，读者看我总结即可：

*  笔者发现某些机型上出现页面白屏情况；
 *  出现在报错页面上的信息非常明显，即当前浏览器不支持 `...` 扩展运算符；
 *  出错的代码（使用了扩展运算符的代码）属于某个公共库代码，它没有使用 Babel 插件进行降级处理，因此线上源代码出现了 `...` 扩展运算符。

现在问题找到了，或许直接将出现问题的公共库代码用 Babel 进行编译降级就可以了。在文中环境下，需要在 `vue.config.js` 中加入对问题公共库 `module-name/library-name` 的 Babel 编译流程：

transpileDependencies: [
      'module-name/library-name' // 出现问题的那个库
    ],

vue-cli 对 transpileDependencies 也有如下说明：

> 默认情况下 babel-loader 会忽略所有 `node_modules` 中的文件。如果你想要通过 Babel 显式转译一个依赖，可以在这个选项中列出来。

按照上述操作，却得到了新的报错：`Uncaught TypeError: Cannot assign to read only property 'exports' of object '#<Object>'`。

究其原因，`module-name/library-name` 这个库对外输出的是 CommonJS 类型源码，我们对该库进行编译后，项目基础设施中会通过 babel-transform-runtime 在编译时增加 helper 代码，而这些 helper 使用的是 import 引入。**最终编译结果出现了 ESM 包含 CommonJS 的情况，是不会被 Webpack 处理的**。

我再次分析下出现的新的问题：

*  plugin-transform-runtime 会根据 sourceType 选择注入 import 或者 require，sourceType 的默认值是 module，就会默认注入 import；
 *  Webpack 不会处理包含 import/export 的文件中的 module.exports 导出，所以需要让 Babel 自动判断 sourceType，根据文件内是否存在 import/export 来决定注入什么样的代码。

为了适配上述问题，Babel 设置了 `sourceType` 属性，`sourceType：unambiguous` 表示 Babel 会根据文件上下文（比如是否含有 import/export）来决定是否按照 ESM 语法处理文件。

这时候就需要配置 Babel 内容了：

module.exports = {
      ...  // 省略的配置
      sourceType: 'unambiguous',
      ...  // 省略的配置
    }

**但是这种做法在工程上并不推荐，上述更改方式对所有编译文件都生效**，但也**增加了编译成本**（因为设置 `sourceType：unambiguous` 后，编译时需要做的事情更多），还有个潜在问题：

> Unambiguous can be quite useful in contexts where the type is unknown, but it can lead to false matches because it's perfectly valid to have a module file that does not use import/export statements.

翻译过来，就是说并不是所有的 ESM 模块（这里指使用 ESNext 特性的文件）都含有 import/export，因此即便某个待编译文件属于 ESM 模块，也可能被 Babel 错误地判断为 CommonJS 模块而引发误判。

\*\*基于这一点，一个更合适的做法是：\*\*只对目标第三方库 `'module-name/library-name'` 使用 `sourceType：unambiguous`，这时 Babel overrides 属性就派上用场了：

> Allows users to provide an array of options that will be merged into the current configuration one at a time. This feature is best used alongside the "test"/"include"/"exclude" options to provide conditions for which an override should apply.

具体使用方式：

module.exports = {
     ...  // 省略的配置  
     overrides: [    
      { include: './node_modules/module-name/library-name/name.common.js',  // 使用的第三方库      
      sourceType: 'unambiguous'    
      }  
     ], 
      ...  // 省略的配置
    };

至此，这个“iOS 11 系统白屏”问题就算告一段落了（你有没有被各种配置和设计搞得云里雾里？）。

我整理了解决路线，如下图所示：

![0a645f722c5307376f6812f94bc38f05.png][]![0f81b4588d47b560eb3bf3704f9f0448.png][]

**我们回过头再来看这个问题，问题其实出现在一个公共库上，因而前端生态的混乱和复杂也许是更本质的原因，但这都转嫁为前端工程化的难点。**

**我们进一步思考：**

*  作为公共库，我应该如何构建编译代码，让业务方更有保障地使用？
 *  作为使用者，我应该如何处理第三方公共库，是否还需要对其进行额外编译和处理？

被动地发现问题、解决问题只会让我们被「牵着鼻子走」——这不是我们的目的。感兴趣的读者可以点赞，关注，我会很快输出更多关于「前端工程化」的内容。

--------------------

## 最后的话 ##

对于很多前端工程师来说，你可能配置过 Babel/Webpack，也可能看过一些关于 Babel/Webpack 插件或原理的文章。但我认为，通过阅读几篇 Babel/Webpack 插件编写甚至 AST 分析的文章并不能让我们真正掌握前端工程化。这也完全完全不是前端工程化的要义。

「配置工程师」只是我们的起点。作为前端开发者，你可能会被繁琐的配置和工具所困扰，自己的终端脆弱无比，出现各种报错。此时，你可能花费了一天的时间，通过 Google 找到了最终的配置解法；或者通过：

rm -rf node_modules + npm install + npm run dev

规避了问题。但是解决之道却没搞清楚，得过且过，今后依然被类似的困境袭扰。

当我们对配置、工具、构建流程、架构设计、生产发布等环节的各种挑战和问题能有系统化的思考时，「前端工程化」自然也不会再是一个困惑。

其实很抱歉我无法回答题主这个宏大的问题，我自己也受此困扰，仅以两个小的细节方面抛砖引玉（**闲时我也会持续输出更多关于「前端工程化」的内容**）。

总之，前端既收获着快速发展，也迎接着批量劣汰；前端技术有着与生俱来的混乱，也有着与之抗衡的规范 —— 这都对前端工程化提出了更高的挑战。

## 最后 ##

欢迎关注【前端瓶子君】✿✿ヽ(°▽°)ノ✿

回复「算法」，加入前端算法源码编程群，每日一刷（工作日），每题瓶子君都会很认真的解答哟！

回复「交流」，吹吹水、聊聊技术、吐吐槽！

回复「阅读」，每日刷刷高质量好文！

如果这篇文章对你有帮助，「在看」是最大的支持

![6f740736cb5c3ca8e7547dd0fe96408d.png][]

》》面试官也在看的算法资料《《

“在看和转发”就是最大的支持

[fffca70a1a57d38fc3182a75755cf74c.png]: /images/20221022/ec8fa95379b24ae0a63d181d05e81c97.png
[5fefb2117f0cbd072863beb04fdf7a91.png]: https://img-blog.csdnimg.cn/img_convert/5fefb2117f0cbd072863beb04fdf7a91.png
[5cc8f2fc9ab0db608a513f74c2217f52.png]: https://img-blog.csdnimg.cn/img_convert/5cc8f2fc9ab0db608a513f74c2217f52.png
[H5 _ iOS 11]: http://mp.weixin.qq.com/s?__biz=MzUzNjk5MTE1OQ%3D%3D&chksm=faec89d1cd9b00c791efc2ca5087d4fffa7d51e70b86d19bbf5397c47effe8af78d3ac4f1677&idx=2&mid=2247486729&scene=21&sn=65c08883299e79c9d42a62e6abadf3ef#wechat_redirect
[0a645f722c5307376f6812f94bc38f05.png]: https://img-blog.csdnimg.cn/img_convert/0a645f722c5307376f6812f94bc38f05.png
[0f81b4588d47b560eb3bf3704f9f0448.png]: https://img-blog.csdnimg.cn/img_convert/0f81b4588d47b560eb3bf3704f9f0448.png
[6f740736cb5c3ca8e7547dd0fe96408d.png]: https://img-blog.csdnimg.cn/img_convert/6f740736cb5c3ca8e7547dd0fe96408d.png