首页

我们开发中经常会碰到 package.json 里面的软件包 的版本号前边有 ，^，甚至有的有 >, < 等标识，那他们都是什么意思呢？
想要知道，^，>，< 这些字符什么意思，我们先去了解一下什么是 npm 的语义版本控制

npm 的语义版本控制

语义版本控制：所有的版本都有 3 个数字： x.y.z 。

  • x 代表的是主版本（当进行不兼容的 API 更改时，则升级主版本）
  • y 代表的是次版本（当以向后兼容的方式添加功能时，则升级次版本）
  • z 代表的是补丁版本（当进行向后兼容的缺陷修复时，则升级补丁版本）

这是一种约定，每个 npm 包必须遵守该约定，因为整个系统都依赖于此。

因为 npm 设置了一些规则，可用于在 package.json 文件中选择要将软件包更新到的版本（当运行 npm update 时）。

规使用了以下这些符号：

  • ^ ：只会执行不更改最左边非零数字的更新。（如果写入的是 ^0.13.0，当执行 npm update 时，可以更新到 0.13.1、0.13.4 等，但不会更新到 0.14.0 或更高的版本。如果写入的是 ^1.13.0，当执行 npm update 时，可以更新到 1.13.1、1.14.0 等，但不会更新到 2.0.0 或更高的版本）
  • ~ ：如果写入的是～0.13.0，当执行 npm update 时，会更新到补丁版本：即 0.13.1。但 0.14.0 不可以
  • < ：接受低于指定版本的任何版本。
  • <= ：接受等于或低于指定版本的任何版本。

  • ：接受高于指定版本的任何版本。

  • = ：接受等于或高于指定版本的任何版本。

  • = ：接受确切的版本。
    • ：接受一定范围的版本。（例如：1.2.0 - 1.6.0）
  • || ：组合版本。（例如 < 2.1 || > 2.6 ）

还有其他一些规则：

  • 无符号：仅接受指定的特定版本。（例如 1.2.1 ）

  • latest : 使用可用的最新版本。

    还有一方面的思考是近期对项目依赖的组件库进行了升级，发现经常会有样式污染的问题，如果加上 ^ 去指望组件库的开发者修复污染问题的话，不能确定会不会带来新的污染问题。这种情况还是更应该由组件库的开发们可以提高组件库的稳定性，从测试版本开始发布，减少这些问题。

  • 版本号的使用规范如下：

    • 版本号的命名遵循语义化版本 2.0.0 规范，格式为： 主版本号。次版本号。修订号 ，通常情况下，修改主版本号是做了大的功能性的改动，修改次版本号是新增了新功能，修改修订号就是修复了一些 bug。
    • 如果某个版本的改动较大，并且不稳定，可能如法满足预期的兼容性需求，就需要发布先行版本，先行版本通过会加在版本号的后面，通过 “-” 号连接以点分隔的标识符和版本编译信息：内部版本（alpha）、公测版本（beta）和候选版本（rc，即 release candiate）。