dependence 和 peerDependence 的抉择

[WuHuSa]

哈喽 proCom 的维护者们，请教个问题哈🙏🏻
背景：我们团队有个基础组件库，定位类似 antd，而各个团队业务存在定制 业务组件库的诉求，类似 proComponents。而我们在 dependence 和 peerDependence 的抉择上有一点犹豫。

peer
优势是业务侧可以统一原子组件版本，并更灵活的升/降原子组件版本，进而避免依赖提升失败时版本不一致带来的重复打包、css 变量冲突等问题；
劣势也是可见的，即依赖需要开发者手动安装，体验上略差；并且未来如果用到原子库新版本功能，发版后业务侧也得手动升级原子库（就成了不得不强制用户升级原子组件版本）。

dependence
优势是通常情况下，可以让业务侧无感知原子组件，直接锁死版本，升/降级都可以业务组件库控制，通常体验更好些
劣势是，如果以后依赖原子的中间层多了，版本冲突可能性会提升，就会出现重复打包、css 冲突等问题；同时，业务如果还是需要原子组件（有时会基于原子定制些什么），为避免影子依赖，还是得安装一下，为了避免 css 冲突、重复打包等，就需要对齐锁死版本，这就不利于灵活消费原子组件的 fix、feature 等

想请教下 proCom 团队的朋友们是否有什么经验和建议，帮帮孩子🙏🏻[手动比心]
@chenshuai2144 @afc163

[xliez]

我选peer
从你列举的优劣对比来讲，peer的劣势明显更轻，甚至我觉得称不上劣势：

1. 依赖需要开发者手动安装，体验上略差：估计也就项目初始化的时候安装下peer，后续不会多次安装
2. 如果用到原子库新版本功能，发版后业务侧也得手动升级原子库： 使用新feature需要升级版本，很合理，或peer依赖锁住major即可