Npm 版本控制——这个边缘案例是如何工作的？答案

【问题标题】：Npm versioning - how does this edge case work?Npm 版本控制——这个边缘案例是如何工作的？
【发布时间】：2014-12-23 21:20:13
【问题描述】：

我试图弄清楚 npm 版本控制是如何工作的，因为我被两个无效的包卡住了。参考my other question。我需要的模块，串行端口，使这些包无效，“可读流”和“字符串解码器”。 Serialport 已下载此版本：

readable-stream@1.0.27-1

串口依赖是

"readable-stream": "~1.0.2"

可读流可用版本是：

....
'1.0.26',
'1.0.27-1',
'1.0.31',
....

这解释了为什么选择 1.0.27-1。由于波浪号和 ~1.0.2，这意味着这三个数字必须存在于每个版本中。参考Jakob Mattsson´s simple article

可读流下载

string_decoder@0.10.25-1

可读流再次取决于

"string_decoder": "~0.10.x"

而string_decoders可用的版本是

....
'0.10.24',
'0.10.25-1',
'0.10.25',
'0.10.31',
'0.11.10-1'
....

那个版本是怎么下载的？参考the article again，波浪号表示版本号必须有0.10，x是什么存在？

为什么没有选择 string_decoder@0.10.31？

我相信我在question 中的问题与调用此额外破折号的预发布有关。我正在尝试收集事实以判断依赖项是否可以更新。

【问题讨论】：

“这解释了为什么选择 1.0.27-1。因为波浪号和 ~1.0.2，意味着这三个数字必须存在于每个版本中。”这并不完全正确。这意味着它必须至少为 1.0.2 并且
docs.npmjs.com/misc/semver
是的，你可能是真的。参考这些行：~1 表示 >= 1.0.0 和 = 1.4.0 和
~1.0.2 不代表any version starting with '1.0.2'。它是“任何版本 >=1.0.2 github.com/npm/npm/issues/6997#issuecomment-68006017

【解决方案1】：

我在 github 上收到了答复，issue answer，我想我会与其他可能想知道的人分享：

semver 范围检查是在语义上完成的，而不是在词法上，所以 1.0.31 应该与 npm@2 匹配：

% semver -r '~1.0.2' 1.0.26 1.0.27-1 1.0.31 1.0.26 1.0.31 我怀疑您看到的行为是由于包 tarball 中包含 bundledDependency 造成的。

请参阅Node app fails to run because of prerelease 以获得更详细的答案以及为什么会发生这种情况。

【讨论】：