extension market

[soda-x]

在插件体系中会被分化为两类大的插件

• 一类是：场景插件
• 另一类是：功能性插件

场景插件指的是：项目级别的插件，更加偏向于适配到一种业务场景。
功能性插件指的是：顾名思义是意在提供某一个通用性功能。

老一版设计

在老一版的设计中我们对场景插件和功能性插件设计的非常复杂，复杂度也直接体现在了 cygnus-extension-market 的代码中，原因在于在原先的设计中，我们的场景插件允许耦合功能性插件，在场景插件中我们允许描述功能性插件，这导致的问题会有两点，安装一个场景插件时，必须先要进行场景依赖分析，同时安装场景插件和功能性插件，才算一个场景插件完整了。同时功能性插件是允许出现在插件市场的，所以这边的复杂度还体现在了，功能性插件是有 scope 的，也就是说，功能性插件一方面有可能需要跟着场景插件的版本走，另外一方面也需要跟着全局环境走。

新一版设计

主要变更

• 场景插件中不允许耦合功能性插件，也就是说在场景插件中不再会有功能性插件的相关描述
• 功能性插件的属性为全局，不再和场景插件有耦合
• 功能性插件和 IDE 内核版本会有耦合，原因功能插件会受限于 IDE 内核变更，但当前，我们不在功能性插件中描述内核版本，而是 IDE 内核做出错兼容，以错误日志的形式告知用户
• 功能性插件如果和某一个场景插件不兼容，允许用户以配置的方式，在场景插件中对功能插件予以设置 disable 或者 enable

beta 版场景插件支持

于此同时从需求场景出发，当前设计中少考虑了 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 中设置。