话不多说，先放上截图和仓库地址：
故事背景
网络抓包
之前公司内部因为开发需要，需要和后端进行接口联调，测试环境的时候，经常会涉及到一些状态改变要看交互样式的问题。比如测试需要测商品的待支付、支付中、支付完成等各种节点的交互样式是否符合预期，这种情况测试一般会去造数据或者让后端改数据库接口。 有的小伙伴可能会用 Charles 修改返回数据进行测试。但是 Charles 的抓包体验和配置体验感觉有点麻烦，不是很友好，所以我们自己做了个抓包&mock工具：
傻瓜式交互一次性解决：抓包、代理、请求转发、接口数据篡改 mock 、跨域访问 等能力，并得到了广泛使用和好评。
文件上传
随着项目开发的继续，有些用户给我们反馈页面加载图片资源比较慢，我们看了一下很多图片资源都没有经过压缩处理，这个时候我们可以通过 webpack 写了一些 loader 来对图片资源进行压缩处理。这个时候我们的图片资源大部分是存放在项目目录下。而有的时候，我们是需要将图片存放于 cdn 上的，此时我们又需要一个图床工具，可以在线存储图片资源。于是乎，我们又整合了图片压缩和上传的功能，做了个图床工具：
性能测评
开发者开发页面的时候，需要对页面的性能进行评估，另一方面也可以把评估报告通知给测试同学，对其进行性能测试。之前大多采用的是 chrome 插件 lighthouse 来做。但是这个东西对未登录用户无法做到性能评估，因为用户未登录直接测评了登录页面，显然不符合预期，其次，每个电脑上都得安装插件，受限于设备的不同，可能会导致性能没有同一的变量（网络、网速、分辨率、CUP 等）。所以我们基于 pupeeteer-core 以及electron 做了一个免登的测评工具：
但是这些还远远不够，我们随着业务的增加，功能愈发的多了起来：我们的埋点检测工具、需求管理工具、前端多环境切换工具 等等等....一方面导致 electron 体积变得臃肿起来，另一方面随着发布频率增加，安装下载的成本也越来越大，很多用户就不愿意再接着安装，因为确实很麻烦。所以我们需要改变，让功能不依赖与容器。这就需要把我们的功能全部独立出去，做成插件化。所以我注意到了 utools
插件化之旅
一开始想到做插件化，无非就是使用 electron 的 webview 能力，实现类似于原生内嵌h5那样的方式，h5 页面可以做独立发布，原生提供 nativaAPI 之间通过 jsBridge 来桥接调用原生的方法。这样实现并无问题，我们也尝试了做了一次。最终思路大概是：
electron webview 方式
1. electron 中使用 webview
<webview src="https://xxx.xx.com/index.html" preload="preload.js" />
2. 实现 bridge
// preload.js
window.rubickBridge = {
sayHello() {
console.log('hello world')
}
}
3. 插件借助 bridge 调用 electron 的能力
<html>
<body>
<div>这是一个插件<div>
</body>
<script>
window.rubickBridge.sayHello()
</script>
</html>
4. 通信
因为 proload.js 是 electron 的 renderer 进程的，所以如果需要使用部分 main 进程的能力，则需要使用通信机制：
// main process
ipcMain.on('msg-trigger', async (event, arg) => {
const window = arg.winId ? BrowserWindow.fromId(arg.winId) : mainWindow
const operators = arg.type.split('.');
let fn = Api;
operators.forEach((op) => {
fn = fn[op];
});
const data = await fn(arg, window);
event.sender.send(`msg-back-${arg.type}`, data);
});
// renderer process
ipcRenderer.send('msg-trigger', {
type: 'getPath',
name,
});
ipcRenderer.on(`msg-back-getPath`, (e, result) => {
console.log(result)
});