这是一个创建于 1427 天前的主题，其中的信息可能已经有所发展或是发生改变。
欢迎前往体验 rubick
基于 npm 的插件管理模式
刚开始设计插件管理的方式是将插件打包成 .zip 的压缩包，然后再将压缩包上传到 CDN 上，点击安装再 download 下来进行解压。但是这样有几个弊端
- 需要一个数据存储服务器，来存储这些压缩包文件，那么这需要一笔费用，这对于一个开源开发者来说很难维持下去。
- 打包机制和解压机制繁琐，对开发者不友好
直到我看到 PicGo 作者关于 PicGo 插件设计思路的文章，我突然觉得基于 npm 的包管理方式不正是我想要的吗，既轻量有省了一笔服务器存储开销： PicGo 插件设计 但这其实也有另一个问题，因为是基于 npm 的管理模式，所以需要开发者提前安装 node 环境，才可以使用 npm。但这在目前是可以接受的，因为 Rubick 的目前定位也是为开发者服务的开源工具箱。
当你点安装插件的时候，其实执行的就是 npm install xxx.
拓展系统插件能力
Rubick 另一个最大的能力就是支持系统插件，有了系统插件，我们就可以不用受限于必须搜索使用插件了，只要 rubick 在运行，插件就在运行。这对于一些特殊的场景来说是非常有价值的事情，比如我要实现一个定时提醒喝水的插件，如果我退出了插件界面，可能就无法实现。但是要做成了系统插件，即使退出了插件，但rubick依旧会在后台运行插件提供的hooks。这个灵感也是来自于 PicGo 的插件生命周期设计。下面来演示系统插件：
有了系统插件，我们就可以实现 屏幕取色插件、定时提醒插件、超级面板插件... 另外，由于 rubick 的系统插件是运行在 main 进程的，所以，我们可以通过系统插件做到更多的能力，比如把 rubick 就看出是 electron 的二次封装，不需要任何 electron 的构建打包，基于系统插件，我们可以实现另一个桌面端应用！
 | 1 Rebron1900 2022-01-07 12:14:45 +08:00 希望尽快完善 |
 | 2 junhao999 2022-01-08 11:15:47 +08:00  1 感觉有点像 utools |
 | 3 kerinlin 2022-01-11 11:20:51 +08:00 这不就是 utools 吗，不过 utools 没开源，这个开源了，还是可以的 |
 | 4 muwoo OP @kerinlin 交互设计参考了 utools ，但整体的架构方案完全不一样哦，插件我们是基于 npm 的管理模式，所以自带支持内网部署，只需要将 npm 源改为自由的即可。 同时支持系统插件，这是 utools 做不到的。所以像超级面板、取色器等等功能都可以抽出插件来 |
 | 5 hansonfang 2022-01-12 10:09:06 +08:00 正好我们想做个工具箱，感觉搞个插件就能直接用了 |
 | 6 Yenben 2022-01-18 11:21:03 +08:00 给力 |
 | 7 slime7 2022-02-15 15:28:09 +08:00 你把 npm 打包进应用里不就不用安装 node 环境就可以装插件了吗，electron 本身就包含了 node ，。看看 poi 的插件安装设计，直接把你执行`npm install xxx`的部分换成`path/to/npm/bin/npm-cli.js install xxx`就行了 |
Select Language