npm中语义化版本号的应用及管理

237 阅读1分钟

0. 前言

之前我们介绍了语义化版本控制,详情可以查看这篇文章。我们了解了为什么要使用语义化版本,使用语义化本版本有什么好处,以及如何定义一个标准的版本号,版本号的定义有什么规则和规范。那么本文我们将看下实际的使用场景:npm中是如何使用语义化版本号来进行包管理的。

1. 规则策略

下面是编辑器Atom项目package.json文件中的部分依赖包配置,文件地址

"dependencies": {
  ...
  "image-view": "git+https://github.com/atom/image-view.git#4b5eb10",
  "incompatible-packages": "file:packages/incompatible-packages",
  "jasmine-json": "~0.0",
  "jasmine-reporters": "1.1.0",
  "jasmine-tagged": "^1.1.4",
  ...
}

我们可以看到,package.json中依赖包的版本号除了正常的版本号还有其他多种格式,包括^ ~,还有url地址,下面我们就介绍一下分别有哪些格式并且他们都是如何使用的

1.1 常规版本

常规版本就是完全按照语义化版本规范要求的格式来定义包版本。如,"jasmine-reporters": "1.1.0"

在安装过程中,会搜寻指定版本的包,如果找不到对应版本的包,将会报错(此处使用的是cnpm

image.png

1.2 控制版本范围

我们还可以指定安装依赖包的范围,有如下几种方式:

>version 必须大于指定版本号
<version 必须小于指定版本号
>=version 大于等于指定版本号
<=version 小于等于指定版本号
version1 - version2 大于等于version1且小于等于version2,相当于 >=version1 <=version2
也可以使用 ||,连接表示或者关系:range1 || range2

npm在安装时,会查询并安装指定范围中的最新版本。如范围中查询不到版本,将报错,如下

image.png

image.png

1.3 通配版本号

这种形式和版本范围一样也不会定义指定版本,通常有如下几种格式:

1.2.x 匹配zhuban
1.x 匹配主版本号为1的所有版本
* 匹配所有版本

和控制范围的版本号一样,通配的版本号,也会安装符合要求的版本号中的最新版本。

1.4 波浪符号匹配

波浪符号(~)和 插入符号(^)匹配方式, 是比较常用的匹配方式。

~号匹配是匹配满足次版本号且超过指定版本的最新版本号的包,如:~1.3.2将会匹配>=1.3.2 <1.4 的最新版本。 在之前的语义化版本的文章中提到修订号的更新是向下兼容的问题和缺陷的修复。使用~进行匹配更新安装不会产生兼容问题,而且可以保证当前次版本号的问题已经被修复。

1.5 插入符号匹配

^号匹配,是匹配满足主版本号且超过指定版本的最新版本号的包,如:^1.2.1将会匹配>=1.2.1 <2.0.0 的最新版本。 在之前的语义化版本的文章中提到次版本号的更新是向下兼容的功能上的调整。使用~进行匹配安装不会产生兼容问题,而且可以保证功能上的更新。

1.6 使用URL匹配

使用URL进行匹配在实际使用中,不是很常见。简单介绍一下,可以使用git url或者本地路径进行安装,如下:

// git url
git+ssh://git@github.com:npm/cli.git#v1.0.27
git+ssh://git@github.com:npm/cli#semver:^5.0
git+https://isaacs@github.com/npm/cli.git
git://github.com/npm/cli.git#v1.0.27

// 本地文件路径,可使用相对路径或绝对路劲
../foo/bar
~/foo/bar
./foo/bar
/foo/bar

总结

npm中通过语义化版本号,可以灵活的对包版本进行管理和更新。实际的开发过程中,我们有时候也会发现,某些包即使更新了次版本号也会发生不兼容的情况。主要原因就在于,定义版本号的不规范。我们在开发的依赖的时候,一定要严格参照语义化版本控制的要求。一方面也是体现我们的专业性,另一方面也是方便使用者的版本管理控制。

参考资料

docs.npmjs.com/cli/v6/conf…