screetbloom/blog

🎸 My Blog

blog

blog's Issues

《美团到店前端工程化演进》文字稿 - GMTC2021

先收敛，二次修改一下再发出

关于基于 Vue CLI 进行企业内二次开发的思考和问题

背景

我本人是 Vue CLI 生态技术的爱好者，期望可以基于 Vue CLI 进行企业内的跨 Vue/React 技术栈的二次定制

企业内的二次定制

1.插件发现策略

目前的 Vue CLI 的插件发现策略是 /^(@vue\/|vue-|@[\w-]+(\.)?[\w-]+\/vue-)cli-plugin-/

但是在公司内，是有一些诉求的：

• 支持具有 React 语言风格的插件：@fe/react-cli-plugin-x
• 跨技术栈插件同时具备公司内品牌形象：@fe/xxx-cli-plugin-x

这个时候直接使用 Vue CLI 就没法满足需求，需要进行侵入式的改造，Fork 是我不愿意采取的形式

2.插件使用打点

在企业内，我们开发一些插件是希望能够具体统计出这个插件服务的范围和使用次数的；比如一个编译提速的插件，需要了解到这个插件的使用范围和次数才能衡量出工具对业务的帮助，比如号称 xxx 工具可以提效人力 20%，但是没有数据是没人认可的

这个需求是需要对插件机制的加载执行进行打点统计的，一般情况下也需要进行侵入式的代码改造

3.插件分析

企业内忌讳重复建设，需要保证大家不会疯狂重复造类似轮子，而是类似能力的轮子可以以共建的方式持续迭代和维护，质量和人力节省上都能有提升
我们采取的策略是进行插件分析，通过大概的 Api + 名称 去判断是否重复

4.业务能力定制

比如目前 Vue CLI 仅在 create 阶段有 preset 能力，而企业内会希望在 service 阶段也能有 preset 能力

1. 收敛 package.json 中的插件数量、对一线同学屏蔽过多插件带来的理解复杂度
2. 企业内使用 Vue CLI 的部分项目 dependencies + devDependencies 数量可以达到 50+，preset 之后可以把 12+ 插件全部收敛，降低理解成本
3. 对比 Umi 也有 preset 能力，只不过叫「垂直场景解决方案」或者「场景套件」

其它的定制能力：

比如

• 部分能力要求 serve 后能够阻塞本地服务器的启动，比如 yarn serve/dev 后进行用户 inquirer 交互式对话
• 拓展 PluginAPI、GeneratorAPI 的 Api 提供给业务同学使用等

And 其它一些诉求

我目前的方案

核心想法是希望能够在按需拓展能力的前提下，同时兼容 Vue CLI 已经沉淀的生态能力

• 插件运行机制：重写了 Vue CLI 的插件发现、注册、加载、执行，兼容原始 Vue CLI 插件的加载和执行
• API：Vue CLI API（PluginAPI、GeneratorAPI）等暴露的是一个个 class，直接 extends 然后按需覆盖、增加
• 内置插件：Vue CLI 的插件基本都是一个个的 js 文件，以形如 require('vue-cli-service4/lib/config/app') 的方式获取此文件，然后直接执行即可，这部分增强的诉求不大

因为「运行机制」是完全重写的，因此可以支持自定义插件命名的发现策略、增加使用打点、插件分析等能力

现有方案存在的问题

• API、内置插件 等可以随着 Vue CLI 生态一起升级，但是这个东西变成了黑盒，require 后并不知道它有什么，就会带来 Vue CLI 迭代过程 Api 或者是 内置插件 文件可能会引入一些我们自己代码不支持的新逻辑新，这个时候就要去定位和兼容
• 大版本兼容的时候成本比较高

想了解一下是否有更优雅的解法

如果 Vue CLI 可以抽象一波，类似 @umijs/core 可能会比较棒
如何定制企业级前端研发框架