是否支持 semver 版本号的 Ranges ?

[sorrycc]

比如：~1.1.0 适配 1.1.0 和 1.1.1 等小版本。详见：https://github.com/npm/node-semver#ranges

感觉是 稳定性 和 便利性 之间的选择。

1. 如果支持
   可能存在潜在的不稳定因素。比如有可能一个依赖模块的小版本更新会导致出现线上故障。spm 在我接触以来已经出现 3-4 次类似问题导致的安装或使用故障。
2. 如果不支持
   同时还会下线 publish -f 和 unpublish 这些可能出现不稳定因素的现有功能。对于使用者会带来不便，比如 anima-yocto 被 23 个模块支持，一个 bugfix 需要同时更新 23 个依赖他的模块，工作量太大。

[sorrycc]

from @lifesinger

一个想法：

1、版本依赖可以支持 semver 的模糊写法，解决一升全升的问题
2、但不到线上才判定最后依赖的版本
3、在构建阶段，提示出来，最终打包的依旧是具体的版本，然后通过测试去保证质量

[popomore]

和 npm 一样，危险的因素是对 semver 的里面，比如一个 fix 版本升级了 minor，导致依赖库无法使用。

[sorrycc]

npm shrinkwrap 可以锁定版本号，不过苏千说不好用。

[SMbey0nd]

昨天自己也梳理了一下，最后发现，不管用哪种形式，都会遇到问题。不是稳定性的问题，就是开发者需要面对的版本依赖更新的便捷性问题。感觉没有很完美的解决办法，只能通过一些良好约定和适中平衡来把握分寸。目前比较赞同语义化版本+模糊写法的方式：

1. 主版本号：当你做了不兼容的API 修改，
2. 次版本号：当你做了向下兼容的功能性新增，
3. 修订号：当你做了向下兼容的问题修正

让大家都严格遵守这个约定来做版本迭代；在对一些底层库设定依赖时，可以用模糊的方式跳过小版本更新。这样一定程度上，可以在稳定和便捷上，有个平衡。

[popomore]

这个问题一直依赖都是知道的，如果开发者能很好的使用 semver，那是很完美的。

但服务器一旦支持这个功能，就很难约束开发者的使用，尤其是底层组件的误用会引起上层组件大范围的不可用。

不过这个都是针对包来说的，最后上线的组件肯定是指定版本的。

[sorrycc]

我觉得可以考虑支持。

然后通过一些约定、限制和提醒来防止在生产环境上滥用。比如：

1. 业务模块的依赖最多只允许 patch 级别的
2. 构建时提醒用户哪些模块包含模糊匹配，确保用户完全
3. publish 时如果包含模糊匹配，进行提醒
4. 对于一些关键业务，考虑支持版本锁定的功能，类似 npm shrinkwrap