共计 1250 个字符，预计需要花费 4 分钟才能阅读完成。
为什么要做 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. 零碎插件能力
Rubick 另一个最大的能力就是支持系统插件，有了零碎插件，咱们就能够不必受限于必须搜寻应用插件了，只有 rubick 在运行，插件就在运行。这对于一些非凡的场景来说是十分有价值的事件，比方我要实现一个定时揭示喝水的插件，如果我退出了插件界面，可能就无奈实现。然而要做成了零碎插件，即便退出了插件，但 rubick 依旧会在后盾运行插件提供的hooks。这个灵感也是来自于 PicGo 的插件生命周期设计。上面来演示零碎插件：
有了零碎插件，咱们就能够实现 屏幕取色插件 、 定时揭示插件 、 超级面板插件… 另外，因为 rubick 的零碎插件是运行在 main 过程的，所以，咱们能够通过零碎插件做到更多的能力，比方把 rubick 就看出是 electron 的二次封装，不须要任何 electron 的构建打包，基于零碎插件，咱们能够实现另一个桌面端利用！
最初
做开源最大的能源是因为酷爱，齐全是非盈利的，心愿做的货色能给须要的小伙伴提供一些帮忙和方向，程序员都是最单纯可恶的，心愿不要歹意攻打突破程开源能源最初一份热衷。
另附：
rubick github 仓库
rubick 应用文档
