关于npm:packagejson-version

介绍

前端开发的过程中须要引入一些第三方包，帮忙咱们疾速高效地开发。当第三方包有批改，咱们更新包的版本时，咱们须要理解包批改的范畴，以便对此做出相干反馈。

为此，由 Gravatars 创办者兼 GitHub 独特创办者 Tom Preston-Werner 建设了语义化版本控制标准（Semantic Version），体现在 npm 包的版本号中。

单个版本号的形成

构造

major.minor.patch(-prerelease)?

• major.minor.patch

  • 三者都为自然数；且都以数值来递增。
  • 正则表白：[1-9][0-9]*

• prerelease

  • 在订正号之后，先加上一个连接号（-）再加上一连串以句号（.）宰割的标识符（[0-9A-Za-z-]）来润饰。
  • 数字型的标识符，为自然数
  • 正则表白：-[0-9A-Za-z-](\.[0-9A-Za-z-])*

major(主版本号)，minor(次版本号)，patch(订正号)，prerelease(后行版本号)

major.minor.patch 为规范版本号。

语义阐明

• major – 当包源代码批改，批改无奈做到向下兼容时，主版本号递增；该批改，能够蕴含次版本号和订正号的状况。
• minor – 当包源代码批改，新增一些向下兼容的性能，次版本号递增；该批改，能够蕴含订正号的状况。
• patch – 当包源代码批改，做了向下兼容的问题批改，订正号递增。
• prerelease – 被加上后行版本号示意该版本并非正式版，存在不稳固的状况。

大小比拟

• 规范版本比拟：major.minor.patch

  • 从左往右，依照数值的大小比拟，例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。

• 后行版本比拟：通过后行版本号中，从左往右的每个被句号离开的标识符来比拟。

  • 只有 数字标识符 比拟时，则按数值的大小比拟。
  • 只有 非数字标识符 比拟时，则依照 每个标识符 中 每个字符 在 ASCII 中的程序来比拟。
  • 数字标识符 和 非数字标识符 比拟时，则 非数字标识符 优先级高。
  • 若每个标识符都雷同的状况，则 标识符层级多 的后行版本号 优先级高。

• 混合比拟

  • 带有 后行版本号 的版本优先级 低于 相关联的 规范版本，例如：1.2.3-beta-1 < 1.2.3

版本的程序

版本号的范畴

背景：为了解决在我的项目中同一个包不同版本的兼容需要，以及安装包时能够降级到预期的最新版本。version 字段能够表白一个版本的范畴。

构造

版本范畴（version range）： (operator version)(joiner(operator version))*

比拟器（comparator）构造为：(operator version)

初始操作符

• <version: 小于某个版本
• <=version: 小于或等于某个版本
• >version: 大于某个版本
• >=version: 大于或等于某个版本
• =version: 等于某个版本；当没有操作符时，默认为等于（=）操作符，因而该操作符能够不必写。

例如：>=1.2.7，将匹配 1.2.7、1.2.8、2.5.3 和1.3.9，但不会匹配 1.2.6 和1.1.0。

连接符（joiner）

• 空格（whitespace）：当比拟器由空格连贯时，相当于且（&&）。例如，>=1.2.7 <1.3.0，将匹配 1.2.7、1.2.8 和1.2.99，但不会匹配 1.2.6、1.3.0 和1.1.0。
• ||：当比拟器由 || 连贯时，示意“或“的意义。例如，1.2.7 || >=1.2.9 <2.0.0，将匹配 1.2.7、1.2.9和 1.4.6，但不会匹配1.2.8 和2.0.0。

与 &&、|| 的优先级一样，空格的优先级高于 || 优先级。

后行版本号的范畴

后行版本号的存在示意该版本为非正式版本，存在不稳固的状况。因而带有后行版本号的比拟器，其版本覆盖范围有以下两点：

1. 正式版本号的范畴。
2. 正式版本号的后行版本号的范畴。

例如：>1.2.3-alpha.3，相当于 >1.2.3-alpha.3 <1.2.4-0 || >1.2.3；将匹配 1.2.3-alpha.7 和 3.4.5，但不会匹配 3.4.5-alpha.9。

只有规范版本号的范畴是无奈匹配任何带有后行版本号的版本号，例如：>1.2.3，将匹配 1.2.4，但不会匹配1.2.4-alpha.9。

高级版本范畴语法

-（Hyphen Ranges）

构造：startVersion - endVersion 相当于 >=startVersion <=endVersion

意义：指定一个版本范畴。

例如：1.2.3 - 2.3.4 相当于 >=1.2.3 <=2.3.4

在该语法下，如果版本号的构造中正式版本号局部有缺失，具体解决逻辑为：开始版本号、完结版本号，别离向两端延长。

例如，开始版本号中的构造有缺失，补 0 解决：

• 1.2 - 2.3.4 相当于 >=1.2.0 <=2.3.4

例如，完结版本号中的构造有缺失，补 X 解决：

• 1.2.3 - 2.3 相当于 1.2.3 - 2.3.x 相当于 >=1.2.3 <2.4.0-0
• 1.2.3 - 2 相当于 1.2.3 - 2.x.x 相当于 >=1.2.3 <3.0.0-0

X（X-Ranges）

X、x、* 在正式版本号中示意为一个数字的占位符，意义为一个自然数。

• * 相当于 >=0.0.0（任何版本都满足）
• 1.x 相当于 >=1.0.0 <2.0.0-0（匹配主版本号）
• 1.2.x 相当于 >=1.2.0 <1.3.0-0（匹配次版本号）

版本号中如有缺失局部，也被当作 X 对待，例如：

• '' 相当于 *
• 1 相当于 1.x.x
• 1.2 相当于 1.2.x

~（Tilde Ranges）

具备残缺版本号构造的前提下，容许订正号级别的降级变动。

例如：

• ~1.2.3 相当于 >=1.2.3 <1.3.0-0
• ~1.2.3-beta.2 相当于 >=1.2.3-beta.2 <1.3.0-0

其余状况，相当于补 X。

• ~1.2 相当于 1.2.x
• ~1 相当于 1.x.x

^（Caret Ranges）

具备残缺版本号构造的前提下，以规范版本号中最左侧第一个非零元素为界线，容许向后低级别元素的降级变动。

例如：

• ^1.2.3 相当于 >=1.2.3 <2.0.0-0
• ^0.2.3 相当于 >=0.2.3 <0.3.0-0
• ^0.0.3 相当于 >=0.0.3 <0.0.4-0
• ^1.2.3-beta.2 相当于 >=1.2.3-beta.2 <2.0.0-0

其余状况，相当于补 X。

例如：
^0.x 相当于 0.x.x

在正式版本之后，^ 符号的版本范畴等同于 主版本号 不改变， 次版本号 和 批改号 能够任意降级变动。

批改版本号

npm CLI 提供了编辑和查看 version 的一系列命令。

查看版本号

npm view <pkg> version：查看某个 pkg latest 标签上的最新版本号。

npm view <pkg> versions：查看某个 pkg 所有公布过的版本号。

编辑版本号

编辑版本号是通过 npm version 命令来操作的。该命令在批改 package.json - version 的同时，也会主动执行 git commit 保留版本号至 git tag。因而在操作该命令之前须要保障 git status 是 clear 的。

npm version <newversion>：newversion 会齐全笼罩 package.json - version 的值。

npm version major：降级主版本号。

npm version minor：降级次版本号。

npm version patch：降级订正号。

npm version --preid=<prerelease-id>：为后行版本号设置一个语义化的前缀。例如，以后版本号为 1.0.1，执行 npm version --preid=alpha 之后，版本号变为 1.0.2-alpha.0。

npm version prerelease：降级后行版本号；例如，以后版本号为 1.0.1-alpha.0，执行 npm version prerelease 之后，版本号变为 1.0.1-alpha.1，再执行 npm version prerelease 之后，版本号变为 1.0.1-alpha.2，以此类推。

最佳实际

开发初始阶段

npm 包的开发初始阶段版本号为：0.a.b，这一阶段的代码被认为不稳固的，还无奈对外颁布。

开发阶段的起始版本号能够为：0.0.0，也能够定为其余版本号，没有限度。

后行版本号

在开发 npm 包 的过程中须要通过一连串的测试环节，通常咱们会看到三种类型的 prerelease，别离是：alpha、beta、rc，例如：

• 1.1.0-alpha.0
• 1.1.0-beta.0
• 1.1.0-rc.0

每种类型的 prerelease 都有其非凡的含意：

• alpha – 内测版本，个别为测试环节的第一步；该版本次要给开发人员和测试人员应用的。
• beta – 公测版本，个别为测试环节的第二步；该版本次要给局部公测用户应用的。
• rc（release candidate）– 候选版本，个别为测试环节的第三步；该版本对外颁布，并且容许局部或者所有的用户应用；这个版本相似 预览版 或 尝鲜版；该版本曾经与正式版本十分靠近了。

在测试过程中，没有必要恪守下面三个测试步骤，开发者能够依据理论须要抉择某个 prerelease 作为测试终结版本，并且对外公布相应的正式版本。例如：当 2.0.0-alpha-1 具备公布正式版的条件时，就能够对外公布 2.0.0 版本。

prerelease 版本号从 0 开始，例如：1.1.0-alpha.0

正式版本

正式版本公布的条件：初期开发阶段测试完结，npm 包 具备对外颁布的条件。

第一个正式版本的版本号为：1.0.0。

从此便开始 npm 包 的维护阶段，依据公共 API 及其批改内容更新版本号。

参考

1. package-json#version
2. semver
3. node-semver
4. NPM package 版本治理最佳实际 #2