跳到正文

Semver 版本范围测试

Semver Range Tester

看哪些版本落在某个范围里,比较两个版本,并把一串版本按优先级排好序。

回答人们关于语义化版本真正会问的两个问题:这个版本满足这个范围吗,以及这些版本里 npm 会安装哪一个。它还按优先级比较两个版本,并显示每种 `npm version` 提升会产生什么。

🔒 完全在你的浏览器里运行semverversionnpm

范围

落在范围里的是:1.0.0 及以上、低于 2.0.0

这是 npm 的范围语法:`^` `~` `x` `-` `||` 和几个比较运算符。semver.org 里没有这套语法,它只规定版本号的格式和先后顺序。

版本列表

一行一个,或者用逗号隔开。

哪些能对上

预发布
  1. —1.0.0-alpha
  2. —1.0.0-alpha.1
  3. —1.0.0-alpha.beta
  4. —1.0.0-beta
  5. —1.0.0-beta.2
  6. —1.0.0-beta.11
  7. —1.0.0-rc.1
  8. 命中1.0.0
  9. 命中1.2.0会装这个
  10. —2.0.0-rc.1
  11. —2.0.0
  12. —2.1.3

比较两个

顺序

1.0.0-beta.11 更高

差别

prerelease

先后顺序完全照 semver.org 第 11 条办:连构建元数据一起——也就是一起忽略掉。

下一个版本

每种发布类型,以及它给出的版本号。
major2.0.0
minor1.3.0
patch1.2.4
premajor2.0.0-alpha.0
preminor1.3.0-alpha.0
prepatch1.2.4-alpha.0
prerelease1.2.4-alpha.0

`npm version <类型>` 会给出的值。

有一条规则让所有人都吃过一次惊:预发布版本只有在范围本身提到同一个 major.minor.patch 的预发布版本时,才算落在这个范围里。所以 ^1.0.0 匹配不上 2.0.0-beta.1,也因此 rc 标签永远不会不小心把自己装上。

怎么用

  1. 写范围

    `^1.0.0`、`~1.2.3`、`>=1.2.7 <1.3.0`、`1.2.3 - 2.3.4` 和 `||` 都可以。下方会出现一段说明它匹配什么的白话描述。

  2. 粘贴你手上的版本

    一行一个,或逗号分隔——`npm view <pkg> versions` 的输出可以直接粘进来。每一个都标出匹配与否,npm 会安装的那个会被标记出来。

  3. 比较两个,或规划下一次发布

    比较面板严格遵循 semver.org 第 11 条。提升表显示从给定起点开始,`npm version major`、`preminor` 等各自会产生什么。

常见问题

为什么 `^1.0.0` 不匹配 `2.0.0-beta.1`?

两个原因同时起作用。`^1` 永远到不了主版本 2;另外,预发布版本只在范围本身指定了同一 major.minor.patch 的预发布版本时才满足该范围。第二条规则正是 `rc` 标签从不会意外把自己装上的原因。

为什么 `^0.2.3` 的行为不一样?

低于 1.0.0 时,脱字符收紧到次版本:`^0.2.3` 允许 0.2.x 但不允许 0.3.0,因为 0.x 的项目被理解为每个次版本都会破坏兼容。这是 npm 的规则而不是 semver.org 的,每次都让人吃惊。

`1.0.0+build.1` 和 `1.0.0` 不同吗?

字符串不同,优先级相同——第 10 条说比较时忽略构建元数据。这意味着对只在构建元数据上不同的版本排序是不稳定的,这样的两个版本根本无法排出先后。

范围语法是 semver 的一部分吗?

不是。semver.org 定义版本格式和两个版本怎么比较,到此为止。`^`、`~`、`x` 和 `||` 是 npm 的范围语法,其他生态要么借用要么替换了它——Cargo、Composer 和 pip 在细节上各不相同。

可以从这些接进来

接下来

这些工具吃得下当前工具的产出,结果可以直接送过去。