• 欢迎访问新概念博客,研究javascript,css3,html5,nodejs,Ext js等技术研究,推荐使用最新版火狐浏览器和Chrome浏览器访问本网站,欢迎加入新概念博客

什么是前端工程化,怎么工程化

欣赏 新概念 来源:网络 4周前 (08-19) 96次浏览 0个评论 扫描二维码

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

主要为了提高开发过程中的开发效率,减少不必要的重复工作时间。

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

随着前端技术不断从 Web 延伸至各种“端”,大前端的概念早已成为业内共识。伴随着大前端的发展,与之相对应的前端工程体系也在不断拓展边界,仅仅只是构建、工具和规范等常规方式已经不足以表达当下前端工程所涉及的领域。

大前端领域涉及的工程能力越来越多样化、复杂化,这是否意味着前端将进入一个新的阶段?前端工程师如何做好准备?


工具篇

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

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

什么是前端工程化,怎么工程化

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

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

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

和工程化主题相关的是:这 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 系统上白屏了!》分析,我先简单梳理和总结一下文章表达的内容,读者看我总结即可:

  • 笔者发现某些机型上出现页面白屏情况;
  • 出现在报错页面上的信息非常明显,即当前浏览器不支持 ... 扩展运算符;
  • 出错的代码(使用了扩展运算符的代码)属于某个公共库代码,它没有使用 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 系统白屏”问题就算告一段落了(你有没有被各种配置和设计搞得云里雾里?)。

我整理了解决路线,如下图所示:

什么是前端工程化,怎么工程化

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

我们进一步思考:

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

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


最后的话

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

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

rm -rf node_modules + npm install + npm run dev 

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

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

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

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


新概念博客 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:什么是前端工程化,怎么工程化
喜欢 (1)
[新概念]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址