Logo

菜单

前端 | package.json 版本号规范

Appleex
Appleex
发布于 2025-06-02 / 50 阅读
0
0
#前端

package.json 版本号规范

简介

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

为此，由 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。

高级版本范畴语法

  1. -（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
  1. 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
  1. ~（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
  1. ^（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 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 及其批改内容更新版本号。

FAQ

参考文献

工具 | MacOS 上使用命令行...
前端 | package.json...

评论