plugin 依赖安装的问题

[JerrysShan]

假设 plugin A 依赖了plugin B，plugin B 插件依赖了plugin C。用户需要在项目里面同时安装 A，B，C，用户怎么感知我要安装这些插件？

对用户来说，可能需要去看 A 的文档，知道我需要安装 B ； 然后再看 B 的文档，才知道我还需要安装 C，这样的体验不是太友好

[DuanPengfei]

能想到两个思路，一个是为用户提供更便捷的获取方式，比如通过 cli 添加 plugin 的依赖而不是直接改文件，这样更可控也更方便我们帮助他处理。这个思路最终还是体现在了代码上，不会黑盒，用户也能看到代码的 diff。

第二个思路是用户只需配置直接依赖的，由构建期去处理，这样会比较黑盒，Egg 好像就是这样的方式 @hyj1991 可以给点建议。

[JerrysShan]

能想到两个思路，一个是为用户提供更便捷的获取方式，比如通过 cli 添加 plugin 的依赖而不是直接改文件，这样更可控也更方便我们帮助他处理。这个思路最终还是体现在了代码上，不会黑盒，用户也能看到代码的 diff。

通过 cli 处理依赖的方式，cli 里面需要预先识别用户所使用的包管理器以及要动态修改用户的plugin 配置文件

[DuanPengfei]

能想到两个思路，一个是为用户提供更便捷的获取方式，比如通过 cli 添加 plugin 的依赖而不是直接改文件，这样更可控也更方便我们帮助他处理。这个思路最终还是体现在了代码上，不会黑盒，用户也能看到代码的 diff。

通过 cli 处理依赖的方式，cli 里面需要预先识别用户所使用的包管理器以及要动态修改用户的plugin 配置文件

是的，这样 cli 就也要做扫描计算的工作，感觉如果朝这个方向发展，那个插件的扫描、依赖计算的功能应该独立出来，有几个地方都要用到了。

这个方式虽然用户感知到很多东西，我理解从清晰度角度看比黑盒好一些，可以再讨论看看，如果没有什么更好的方案时我们可以尝试一下通过 cli 做，然后自己吃一波狗粮看看体验怎么样。

[Beace]

能想到两个思路，一个是为用户提供更便捷的获取方式，比如通过 cli 添加 plugin 的依赖而不是直接改文件，这样更可控也更方便我们帮助他处理。这个思路最终还是体现在了代码上，不会黑盒，用户也能看到代码的 diff。

通过 cli 处理依赖的方式，cli 里面需要预先识别用户所使用的包管理器以及要动态修改用户的plugin 配置文件

兼容主流的包管理器，其他框架冷启动阶段做好提示用户应该也可以接受