这半年多大部分精力都是在做业务组件库，而在业务组件库的开发保护中出我另一个次要做的事就是组件库（或者说是物料资产）的全套工程化流程。

本文不是一篇教学文章，仅是对近半年一部分工作的 流水账式 的总结，也作为本人的一份备忘录，并且因为是公司外部资产很多中央不能贴源码和截图，如果有对其中内容感兴趣的欢送一起探讨。

浅谈前端工程化

在我看来，前端工程化就是指把平时工作流程中的一部分繁琐反复的工作以工具的模式积淀进去，从而缩小开发同学机械化的重复劳动。这里的工具不限于本地我的项目脚本、云端服务等。例如：咱们通过 CRA 去初始化工程项目、通过 Webpack / Vite 对我的项目进行打包构建、通过云端服务对前端我的项目进行上线等等。

从我集体的教训而言，所有开发中波及到的简略的反复机械性劳动，都能或多或少的通过工程化能力失去明显改善。

前端工程化就和性能优化一样旁系泛滥，而本文的次要切入点在于前端工程中的自动化，利用工程自动化的能力浸透物料体系的初始化 -> 开发 -> 构建 -> 上线全副生命周期，回绝所有不高效。

从生命周期看工程化全流程

初始化阶段

对于初始化阶段，物料侧提供了组件 / 区块的初始化模版以不便组件 / 区块的疾速初始化。

开发阶段

作为物料体系的展现站点，蕴含了组件、区块、解决方案、工具汇合等多维度的前端资产，因而采纳 MutiRepo 架构，并齐全脱离传统的 npm link 包开发模式。

• 在组件侧 & 物料侧，开发脚本启动后，实时监听源码的变更并同步到站点的缓存目录。

• 在站点侧，减少 .dev 目录作为本地开发的缓存目录，在 dev 模式下将组件库 alias 到 .dev 开发目录下。并在 Vite 的加持下，继续晋升开发体验。

  • 冷启动阶段，本地开发脚本预检测 .dev 目录合法性，如不非法则全量拷贝 node_modules 下组件源码作为长期缓存文件。
  • 热更新阶段，devServer 监听 .dev 目录文件的变更实时热更新。

更多本地开发相干可查看我之前写的文章：用 Vite 减速你的生产力

构建阶段

物料侧构建阶段只是构建生成 ESM 包和 ES5 的包，这里次要说下站点侧构建时做的事件。

生成文档

因为组件库齐全是通过 ts + 合乎 jsdoc 标准的正文开发的，因而在文档这一步咱们通过脚本：

• 扫描全副组件目录；
• 通过 typedoc 解析组件类型申明以及正文生成文档 AST JSON；

之后站点在 运行时 解析文档 AST JSON 并生成文档。

生成依赖关系

咱们的展现站点又一个性能是展现以后业务组件所依赖的原子组件并生成依赖关系图，和生成文档的逻辑相似，咱们会通过脚本扫描业务组件目录剖析业务组件的 AST 生成依赖关系 JSON，站点会在 运行时 动静加载 JSON 展现依赖桑吉图。

生成组件根本信息

组件的元数据曾经寸在组件源码里存在了，那在站点侧就不须要二次保护了，因而，在生成依赖关系的同时，咱们通过 AST 解析了组件内的元数据，生成了组件根底信息 JSON。站点会在运行时动静加载 JSON 展现组件名、组件设计师、组件形容、组件设计稿等信息。

同步区块代码

之前的文章从业务组件库看前端物料生态分享过，咱们的区块以源码的模式存储，那么在构建时实时拉取最新的源码就是刚需，因而，咱们通过工程化脚本实现了如下性能：

• 对于区块：

  • 读取区块 Container 目录；
  • 剖析 Container 下区块变体依赖；
  • 通过工具拉取主 / 子区块；
  • 站点运行时加载代码；

• 对于解决方案：

  • 读取解决方案下 material.json 文件获取解决方案依赖；
  • 通过工具拉取主 / 子区块；
  • 站点运行时加载代码；

上传 Demo

咱们业务组件库的 Demo 预览实现形式不同于其余组件库，其余组件库是在开发时通过在 markdown 上编写 Demo，编译时将 markdown 解析成 HTML。咱们的业务组件库 Demo 会在站点测以 tsx 源码模式存储，构建时上传到 CDN 上，运行时加载 CDN 源码资源实时预览。

公布阶段

对于从物料到站点的公布，咱们有严格的链式公布流程：

首先对于组件和区块，咱们通过自动化公布工具 materials-tools-release 自动化公布 NPM 和 CDN，缩小了代码合并、分支查看、版本检测、自动化脚本、公布等步骤的老本并升高了出错的危险。

以前的公布（以组件库为例）：

• 这是一种标准，没啥好说的；
• 这一步你可能忘了；
• 这一步你也可能忘了；
• 这一步你也也可能忘了；
• 这一步你也也也可能忘了；
• 这一步可能是你忘的最多的一步，然而能够通过 prepublish 勾子补救；
• 这一步可能是你惟一会执行的；
• 我感觉你可能都不晓得这是个啥；

当初的公布：

步骤少了，出错就少了。

最初是站点部署。

工具积淀

在此过程中，咱们积淀了一套服务于通用组件库场景的工具汇合。

materials-tools-ast

基于 babel 做了二次封装，能够不便的获取文件的导入导出等能力。剖析组件衍生关系

materials-tools-cli

material-tools-cli 次要提供了两局部能力：物料拉取内核 + 物料拉取 cli 工具。其中内核服务于 cli 工具和 vscode 插件次要做了以下这些：

• 辨认物料是否存在，辨认当前目录是否存在同名物料名；
• 依据物料名从 CDN 拉取物料；
• 依据拉取下的物料依赖合并依赖并提醒；

materials-tools-utils

对工程化脚本开发过程中常用工具函数做了封装：

• file.ts：文件操作；
• log.ts：日志输入；
• command.ts：命令行执行操作；

materials-tools-release

自动化公布工具，缩小了代码合并、分支保持、版本检测、自动化脚本、公布等步骤的老本并升高了出错的危险。

工具集的自动化公布

工具集采纳基于 lerna 的 MonoRepo 架构，然而 lerna 并不满足咱们的一些诉求（例如，咱们有很多对立的自定义 npm 勾子的诉求），因而咱们在 lerna 的根底上做了二次封装：

• 通过 lerna changed 获取已更新带公布的包版本信息；
• 通过 lerna version 更新待发布的包版本；
• 依据配置文件排序，例如，a 依赖 b，b 依赖 c，那么排序后就是 c -> b -> a；
• 依据排序后的 list 顺次执行 按自定义 hooks 执行程序顺次执行；
• 公布；