package.json 中的版本是不是应该始终遵循 semver？

Posted 2023-03-07

【中文标题】package.json 中的版本是不是应该始终遵循 semver？

【英文标题】：Should version in package.json follow semver always?package.json 中的版本是否应该始终遵循 semver？

【发布时间】：2018-05-28 07:33:27

【问题描述】：

我需要根据自定义构建版本控制格式修改我的 Angular 应用程序的 package.json。是否必须在版本中遵循 semver，是否存在使用自定义版本格式可能导致 Angular 应用程序出错的情况。

【问题讨论】：

请注意，npm install 适用于自定义版本格式。

【参考方案1】：

不，这不是强制性的，但是您愿意这样做，因为它会为您提供更新的兼容代码。

只要不更改主版本号，应该不会有任何错误。

正如您提到的，使用客户版本格式可以正常工作！

并非每个模块都遵循语义版本控制。一个模块可能使用 由三部分组成的版本号，但可以根据需要增加它们。最安全的 方法是检查模块文档

但是有一个问题

假设您正在使用 1.3.4 版本的库，其中一个波浪号 (~) 作为您的依赖项。图书馆维护良好，发展迅速。今天最新的版本其实是1.5.1。然后发现了一个影响迄今为止每个版本的关键任务错误。该错误得到了适当的处理，并很快在版本 1.5.2 中得到修复。现在很可能没有为您的版本量身定制的错误修复补丁版本 1.3.5，您最终无法获得该错误修复

【讨论】：

优秀文章bytearcher.com/articles/…

为了使事情可重现，您需要将版本号范围替换为确切的版本。为了增强这一点：即使你在你的 package.json 中指定了确切的版本，它并不意味着一个可重现的构建，因为你的依赖项本身通常有更宽松的规范，例如插入符号。在这种情况下，全新安装将选择一个较新的版本作为您的依赖项的依赖项，这仍然可能会破坏。

引用的 npm-shrinkwrap 通过递归依赖树并在*** npm-shrinkwrap.json 的 JSON 树中指定确切版本来解决它，即它不会修改 package.json 文件在你的 node_modules 目录中。这仍然不是 100% 的可重复性保证，因为新代码可能会在相同的补丁版本号下到达。诸如npmjs.com/packa...之类的工具可以提供更好的保证，或者可以对依赖项进行内部源代码控制。