为什么要做 Rubick
其实做 Rubick 1.x 的初衷就是解决自己的问题的：特别需要一款支持自定义插件的桌面端应用来简化使用者安装庞大桌面端应用的臃肿。而且涉及到数据安全的问题，插件只能在公司内网贡献，无法对外公开。
在 Rubick 2.0 的阶段，重新设计了一套基于 npm 的插件管理体系，让开发者更加便利的加入插件的开发。拓展了插件的边界和种类，开发者可以开发 Rubick 系统插件，此时的 Rubick 就成了一个 electron 高级封装，开发者可以高自由的实现系统能力而不局限余 openAPI 也不局限于必须搜索呼起使用，只要 Rubick 在运行，插件就在运行。
Rubick 的自我介绍
Rubick 是基于 electron 的开源工具箱，基于 npm 插件管理的方式自由集成丰富插件。Rubick(拉比克) 出处是 dota 里面的英雄之一，其核心技能是插件化使用其他英雄的技能，用完即走。非常符合本工具的设计理念，所以取名 Rubick。
核心技能展示
1. 基于 npm 的方式管理插件
刚开始设计插件管理的方式是将插件打包成 .zip 的压缩包，然后再将压缩包上传到 CDN 上，点击安装再 download 下来进行解压。但是这样有几个弊端
- 需要一个数据存储服务器，来存储这些压缩包文件，那么这需要一笔费用，这对于一个开源开发者来说很难维持下去。
- 打包机制和解压机制繁琐，对开发者不友好
直到我看到 PicGo 作者关于 PicGo 插件设计思路的文章，我突然觉得基于 npm 的包管理方式不正是我想要的吗，既轻量有省了一笔服务器存储开销： PicGo 插件设计 但这其实也有另一个问题，因为是基于 npm 的管理模式，所以需要开发者提前安装 node 环境，才可以使用 npm。但这在目前是可以接受的，因为 Rubick 的目前定位也是为开发者服务的开源工具箱。
当你点安装插件的时候，其实执行的就是 npm install xxx.
2. 内网使用
如果把插件发布到公网 npm 如果不符合您的公司安全要求，rubick 支持内网私有源和私有插件库，如果您需要内网部署使用，可以自行配置以下规则。
rubick 依赖 npm 仓库做插件管理，依赖 gitee 做插件数据存储，所以如果要进行内网部署，主要需要替换这2个设置。详细设置：
插件市场 -> 设置 -> 内网部署设置
1. 替换 npm 源
插件发布到私有 npm 源即可。
2. 替换 gitee 源为内网 gitlab: database url
- clone 下载 rubick 插件库：https://gitee.com/monkeyWang/rubick-database
- 提交仓库到私有
gitlab库。
替换格式：https://gitlab.xxx.com/api/v4/projects/{projectId}/repository/files/ 。因为接口为 gitlab openAPI，所以需要填写仓库 access_token
3. 系统插件能力
Rubick 另一个最大的能力就是支持系统插件，有了系统插件，我们就可以不用受限于必须搜索使用插件了，只要 rubick 在运行，插件就在运行。这对于一些特殊的场景来说是非常有价值的事情，比如我要实现一个定时提醒喝水的插件，如果我退出了插件界面，可能就无法实现。但是要做成了系统插件，即使退出了插件，但rubick依旧会在后台运行插件提供的hooks。这个灵感也是来自于 PicGo 的插件生命周期设计。下面来演示系统插件：
有了系统插件，我们就可以实现 屏幕取色插件、定时提醒插件、超级面板插件… 另外，由于 rubick 的系统插件是运行在 main 进程的，所以，我们可以通过系统插件做到更多的能力，比如把 rubick 就看出是 electron 的二次封装，不需要任何 electron 的构建打包，基于系统插件，我们可以实现另一个桌面端应用！
最后
做开源最大的动力是因为热爱，完全是非盈利的，希望做的东西能给需要的小伙伴提供一些帮助和方向，程序员都是最单纯可爱的，希望不要恶意攻击打破程开源动力最后一份热衷。
另附：
