在我的JavaScript应用程序中，我可能在package.json文件中声明了几十个依赖项。
需要一段时间才能浏览每个依赖项，并查看它们所处的版本。
我只想说：使用最新的主要版本，但不是最前沿。
作为一个例子，使用像Git这样的工具我通常不关心在补丁级别进行更改，但如果出现新的主要版本，我会想要它。
在指定npm模块的版本时是否有类似的概念？
答案 0 :(得分：5)
NPM包（理论上）使用SemVer。
在SemVer中，软件包的版本号为X.Y.Z。
Z表示错误修复。 Y表示新功能而不更改现有功能。 X表示打破向后兼容性的主要版本。
执行npm install --save <package>会在package.json ^2.3.9中生成一个版本字符串，这意味着＆＃34; 2.*范围内的任何内容都大于或等于2.3.9 {1}}＆＃34 ;.这意味着您将获得错误修复和不间断的新功能，但您不会意外地更新到破坏您的应用程序的3.0.0版本。
注意：我说＆＃34;理论上＆＃34;因为不是每个人都坚持SemVer的理想。您可能会发现2.3.9 -> 2.3.10升级有时会破坏内容。测试很方便。
答案 1 :(得分：1)
使用 npm i -S <pkg> 通常应该做正确的事情。
一些警告：
如果您对<pkg>采用运行时依赖性，则上述假设。在安装开发人员工具（例如grunt）时，请使用 -D 或 -G ，而不是 -S < / strong>即可。
Semantic versioning rule 9表示发布商可以使用-beta这样的后缀来识别预发布版本。 Npm取决于它，因此如果软件包发布者 FAILS 这样做，您可能会在不知道它的情况下依赖预发布包。复杂的npm发布者应该知道更好，并且复杂的npm消费者应该检查文档。
主要版本是' 0 '表示程序包仍在初始开发中，并且程序包不应该被认为是稳定的。 （Semantic versioning rule 4。）
考虑使用 npm dist-tag ls <pkg> 查看是否有一些特定于程序包的标记可以比latest更好地标识您的意图。如果是，请使用 npm I -S <pkg>@<tag> 来跟踪该标记。
您始终可以使用 npm outdated 来检查您是否直接依赖于具有新主要版本的软件包可能需要考虑升级到。按照设计，主要版本升级不会自动发生。