如何详细理解package.json中管理依赖包的版本控制？

本文共计1680个文字，预计阅读时间需要7分钟。

目录：npm版本号定义与package.json中的依赖版本识别

一、npm版本号定义

npm版本号通常遵循语义化版本控制，格式为X.Y.Z，其中：

- X代表主版本号，表示项目的主要更新。- Y代表次版本号，表示项目的新功能或非破坏性更改。- Z代表修订号，表示项目的微小修复或bug修复。

二、package.json中的依赖版本识别

在package.json文件中，依赖关系通过以下字段定义：

1. dependencies：生产环境依赖

2.devDependencies：开发环境依赖

3.peerDependencies：依赖的包版本要求

以下是具体说明：

1. dependencies

- 包含项目运行所需的所有依赖。 - 版本号格式：X.Y.Z - 示例：`express: ^4.17.1`

2. devDependencies - 包含项目开发所需的所有依赖。 - 版本号格式：X.Y.Z - 示例：`webpack: ^4.44.2`

3. peerDependencies - 包含项目运行时需要依赖的包版本要求。 - 版本号格式：X.Y.Z - 示例：`lodash: ^4.17.15`

三、参考npm版本号定义

在定义依赖版本时，可以参考以下规则：

1. 使用^符号表示允许主版本号更新，次版本号和修订号保持不变。

2.使用~符号表示允许次版本号更新，修订号保持不变。

3.使用*符号表示允许所有版本更新。

示例：

- `express: ^4.17.1`：允许主版本号更新，次版本号和修订号保持不变。

- `webpack: ~4.44.2`：允许次版本号更新，修订号保持不变。- `lodash: *`：允许所有版本更新。

总结：

在package.json中，通过dependencies、devDependencies和peerDependencies字段定义依赖关系，并使用npm版本号来指定依赖版本。在定义依赖版本时，可以参考语义化版本控制规则，以确保项目稳定性和兼容性。

目录

• npm版本号定义
• package.json怎么识别依赖版本
• 不要太相信npm包的版本号
• dependencies、devDependencies与peerDependencies
• dependencies
• devDependencies
• peerDependencies
• 参考

npm版本号定义

版本格式：X.Y.Z[-string]其含义为：

• X：主版本号
• Y：次版本号
• Z：修正版本号
• string: 先行版本号或版本编译信息

举个例子：

6.3.2-alpha的含义为：

主版本号6，有6次不可向下兼容的更新迭代。

次版本号3，有3次小的功能迭代。6.*.* <=6.3.2的依赖声明，都可以安装此新包。

修正版本号2，有2次bug修改或其他非重大功能的修改。6.*.* <=6.3.2的依赖声明，都可以安装此新包。

先行版本号alpha，表示处理试验阶段。

扩展阅读：语义化版本 2.0.0

package.json怎么识别依赖版本

将按下述代码进行阐释：

"vue": "~2.5.22", "vue-class-component": "^6.0.0", "vue-router": "3.0.1", "express": "latest", "mongoose": "*",

• 符号^：锁定主版本，可更新次版本号、修正版本号和先行版本号
• 例如"vue-class-component": "^6.0.0"，安装依赖时，可以安装符合6.*.* 的任意版本，只要主版本号是6即可。
• 符号~：锁定主版本号和次版本号，可更新修正版本号和先行版本号
• 例如"vue": "~2.5.22"，安装依赖时，可以安装符合2.5.*的任意版本。
• 空符号：锁定所有版本号
• 例如"vue-router": "3.0.1"，只能安装版本为3.0.1的依赖包。
• 符号*：定义某个版本号范围
• 例如vue-router": "3.0.*"，可以安装3.0固定的任意版本，比如3.0.1、3.0.2。
• latest：安装最新的稳定版本

例如"express": "latest"，可以安装4.18.1 (2022.06.13最新版本)。

*：安装最新发布的版本，不一定是稳定版本

例如"mongoose": "*",可以安装6.0.0-rc2、3.9.7等。

Git URL：使用Git上发布的包

引用格式： <protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]

"test": "git+ssh://git@github.com:npm/cli.git#v1.0.27"

扩展阅读：npm docs - dependencies

不要太相信npm包的版本号

如题，这个是血的教训换来的经验。

笔者在使用system.js时，使用的版本限制是：system.js: "^6.3.2"。

在安装依赖的时候，意外安装了> 6.3.2的版本，导致项目运行出错。

原因就是system.js作者，没有按照semver规范，进行版本号命名，导致笔者的项目，引入了不可向下兼容的更新，进而使项目运行出错。

dependencies、devDependencies与peerDependencies

dependencies

生产环境中使用到的依赖，统一安装在dependencies下。

举个例子：

"dependencies": { "chalk": "^2.4.2", "commander": "^3.0.0", "fs-extra": "^8.1.0", "inquirer": "^6.5.0", "mem-fs": "^1.1.3", "mem-fs-editor": "^6.0.0", "shelljs": "^0.8.3" }

上述代码，是笔者做的cli工具包的package.json中的片段。

shelljs用于操作文件，如果改在devDependencies声明，则用户安装当前工具包后，运行会报错。

因为devDependencies字段声明的依赖，在npm install 工具包时，是不会安装的。

必须在dependencies字段中声明，才会被安装。

devDependencies

生产环境不需要使用的依赖，都需要安装在peerDependencies下。

因为生产环境下，是不会安装devDependencies字段下的依赖的。

举个例子：

"devDependencies": { "@commitlint/cli": "^8.1.0", "@commitlint/config-conventional": "^8.1.0", "commitizen": "^4.0.3", "commitlint-config-cz": "^0.12.1", "cz-customizable": "^6.2.0", "standard-version": "^7.0.0" }

上述代码，是笔者做的cli工具包的package.json中的片段。

commitizen是笔者用于规范Git提交规范的依赖包，只在开发环境中使用，所以在devDependencies中声明。

peerDependencies

当开发一些插件和工具包时，对使用方的运行环境的依赖包版本有要求，可以使用peerDependencies字段进行声明。

举个例子：

{ "name": "tea-latte", "version": "1.3.5", "peerDependencies": { "tea": "2.x" } }

当前工具tea-latte，依赖tea包。而且，要求tea包是主版本2。

当不满足要求时，控制台会进行报错处理。

注意

npm v7版本, peerDependencies会默认安装。

npm v3 到 npm v6版本,peerDependencies不会自动安装。

参考

npm Docs

语义化版本 2.0.0

以上就是package.json管理依赖包版本详解的详细内容，更多关于package.json管理依赖包版本的资料请关注自由互联其它相关文章！