Open soda-x opened 6 years ago
在插件体系中会被分化为两类大的插件
场景插件指的是：项目级别的插件，更加偏向于适配到一种业务场景。 功能性插件指的是：顾名思义是意在提供某一个通用性功能。
在老一版的设计中我们对场景插件和功能性插件设计的非常复杂，复杂度也直接体现在了 cygnus-extension-market 的代码中，原因在于在原先的设计中，我们的场景插件允许耦合功能性插件，在场景插件中我们允许描述功能性插件，这导致的问题会有两点，安装一个场景插件时，必须先要进行场景依赖分析，同时安装场景插件和功能性插件，才算一个场景插件完整了。同时功能性插件是允许出现在插件市场的，所以这边的复杂度还体现在了，功能性插件是有 scope 的，也就是说，功能性插件一方面有可能需要跟着场景插件的版本走，另外一方面也需要跟着全局环境走。
主要变更
于此同时从需求场景出发，当前设计中少考虑了 beta 版的设计，在对应主体 IDE 中会有 beta 版本的概念，在 beta 版本中我们可以对 beta 版本的场景插件予以透出，而正式版则不予透出。这对场景插件本身的状态管理有了更多一层需求，当前我们走的全部是 latest 的 tag（npm 的 dist-tag），如果要支持 beta 这个概念可以有两种实现的手段，一种是在改 publish 的脚本，可以做到同一个仓库，有两个不同的 name 的 pakcage 然后在 beta 版 ide 中默认开启 beta 的白名单， 这种好处是非常简单，下载不同的场景插件即可达到正式开发或者尝鲜的目的；另外一种则是通过走不同的 tag 来予以实现，也就是意味着在 semver 时需要同时比对多个 dist-tag，这种方式的好处是，对一个 package 管理，但复杂度提升不少，稳定版 和 beta 版不能予以兼容。
当前我们的处理方式选择了第二种，如果在 beta IDE 中会对比 latest 和 beta 这两个 tag，alpha 的接入由开发者自己在 IDE 中设置。
在插件体系中会被分化为两类大的插件
老一版设计
在老一版的设计中我们对场景插件和功能性插件设计的非常复杂，复杂度也直接体现在了 cygnus-extension-market 的代码中，原因在于在原先的设计中，我们的场景插件允许耦合功能性插件，在场景插件中我们允许描述功能性插件，这导致的问题会有两点，安装一个场景插件时，必须先要进行场景依赖分析，同时安装场景插件和功能性插件，才算一个场景插件完整了。同时功能性插件是允许出现在插件市场的，所以这边的复杂度还体现在了，功能性插件是有 scope 的，也就是说，功能性插件一方面有可能需要跟着场景插件的版本走，另外一方面也需要跟着全局环境走。
新一版设计
主要变更
beta 版场景插件支持
于此同时从需求场景出发，当前设计中少考虑了 beta 版的设计，在对应主体 IDE 中会有 beta 版本的概念，在 beta 版本中我们可以对 beta 版本的场景插件予以透出，而正式版则不予透出。这对场景插件本身的状态管理有了更多一层需求，当前我们走的全部是 latest 的 tag（npm 的 dist-tag），如果要支持 beta 这个概念可以有两种实现的手段，一种是在改 publish 的脚本，可以做到同一个仓库，有两个不同的 name 的 pakcage 然后在 beta 版 ide 中默认开启 beta 的白名单， 这种好处是非常简单，下载不同的场景插件即可达到正式开发或者尝鲜的目的；另外一种则是通过走不同的 tag 来予以实现，也就是意味着在 semver 时需要同时比对多个 dist-tag，这种方式的好处是，对一个 package 管理，但复杂度提升不少，稳定版 和 beta 版不能予以兼容。