[ 草案规划 ] 关于拓展层的设想 about rubick

[nxnminieye]

插件也可以转化为”拓展层 + UI层“组合的模式。将插件自身功能注册到全局功能注册表中，供插件之间交叉调用

拓展层可以和现有插件兼容,在preload.js中暴露提供的功能,然后其他需要调用这个扩展层的插件,增加个字段

"runtime": [
    "runtime1.name", "runtime2.name"
 ]

加载扩展层插件的preload.js就可以了

[SOVLOOKUP]

插件也可以转化为”拓展层 + UI层“组合的模式。将插件自身功能注册到全局功能注册表中，供插件之间交叉调用

[SOVLOOKUP]

如何在插件开发生产环境中处理插件间的依赖关系?

可能的解决方案:

1. 建立一个开发者中心插件，为开发者提供插件调试环境

2. 处理版本管理的问题，我想可以复用 npm 的包管理系统，让开发者把自己的插件发布到 npm ， rubick 也从 npm拉取插件安装。

[muwoo]

如何在插件开发生产环境中处理插件间的依赖关系?

可能的解决方案:

1. 建立一个开发者中心插件，为开发者提供插件调试环境
2. 处理版本管理的问题，我想可以复用 npm 的包管理系统，让开发者把自己的插件发布到 npm ， rubick 也从 npm拉取插件安装。

这个正是我想搞的，计划把插件全部托管到npm上，通过npm进行管理。目前也正在进行

[renmu123]

这里可以参考obsidian插件的处理方式，插件本身都是开源托管在GitHub中，插件开发者需要pr自己的插件信息到软件的插件.json中。这样可以达成某种程度上的审核，以及不占用额外的看见，缺点介绍国内用户下载可能有问题，可能可以支持码云等国内托管平台

[muwoo]

这里可以参考obsidian插件的处理方式，插件本身都是开源托管在GitHub中，插件开发者需要pr自己的插件信息到软件的插件.json中。这样可以达成某种程度上的审核，以及不占用额外的看见，缺点介绍国内用户下载可能有问题，可能可以支持码云等国内托管平台

so surprise! 这个感觉可以！感谢，有灵感了

[SOVLOOKUP]

jsdelivr.com 有 github 的全球 CDN, 通过这个渠道国内也能正常下载 github 上托管的插件