- 自己的项目出了一点小问题, 需要通过更新依赖来解决
- 版本依赖是:
^0.1.23, 我希望通过npm update升级到0.2.3 - 执行
npm update后, 发现依赖并没有更新, 还是原来的0.1.23; 可以先了解一下 package.json中库的版本号及npm的更新规则 - 通过执行
npm view xx versions(用xx代替我使用的包), 发现确实已经有0.2.3了 - 不纠结, 直接指定版本下载
npm install xx@0.2.3, 执行npm ls查看已经更新成功了 - 虽然已经解决了问题, 但是我们还是来看一下
npm内部的处理逻辑
以 webpack 包为基础进行测试
- 初始化一个测试环境
mkdir demo && cd demo && npm init -y
// package.json
{
"name": "demo",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC"
}
- 先执行
npm view webpack versions查看可以使用的版本有哪些
[
'0.1.0', '0.1.1', '0.1.2', '0.1.3',
'0.1.4', '0.1.5', '0.1.6', '0.2.0',
'0.2.1', '0.2.2', '0.2.3', '0.2.4',
// ..., 数据较大 删除了中间部分
'5.86.0', '5.87.0', '5.88.0', '5.88.1',
'5.88.2'
]
- 我们执行
npm i webpack@5.86.0 -D下载5.86.0版本并添加到devDependencies中 - 这时候在
package.json文件中会新增这一部分
{
// ....
"devDependencies": {
"webpack": "^5.86.0"
}
}
- 执行
npm ls后, 可以看到我们按照的依赖也是webpack@5.86.2 - 我们执行
npm update webpack来更新我们的webpack依赖 - 再执行
npm ls后查看更新后的依赖版本为webpack@5.88.2, 可看到我们更新成功了(package.json也更新了)
下面我们继续, 做一个对比
- 我们执行
npm i webpack@0.1.0, 下载最开始的版本
{
// ...
"webpack": "^0.1.0"
}
- 依赖肯定也是
webpack@0.1.0我们就不做验证了, 我们直接执行npm update webpack更新依赖 - 这个时候
package.json并没有发生变化, 按照上面的结论是会发生变化的 - 先说一下我们的预期结果: 理论上只需要保证第一个版本号不变就可以了, 结果应该是:
webpack@0.2.4(假设是上表数据); - 执行
npm ls查看结果，结果是webpack@0.1.6, 虽然比原版本高，但不是我们预期的结果。
原因
^ 要求: 主版本号相同即可, 并且不超过最 左边非零 数字
并且说的有点绕其实通俗的就是: 第一位是 0 时, 那他的行为和 ~ 一致, 即: 主版本号和次版本号必须相同, 补丁版本任意
小结
- 文中使用过的 npm 命令
npm update更新依赖版本npm view查看依赖信息npm installnpm i按照依赖npm init初始化项目npm ls查看项目的依赖关系
- 在用
^规定包的更新规则时, 需要注意0开头的依赖^表示主版本号相同的版本- 但第一位是
0时, 那他的行为和~一致, 即: 主版本号和次版本号必须相同, 补丁版本任意
- 其实有一个命令更适合这个demo，这里简单的做个介绍吧
npm outdated检查过时的包- 会列一个表，提供的内容有 包名称, 当前版本, 可以升级的版本, 最新版本, 包位置等信息
- 只要执行
npm outdated其实就可以得到 如果执行npm update会安装哪个包，我们上面的操作可以简化很多。 - 下面是执行
npm outdated的一个示例
Package Current Wanted Latest Location Depended by
webpack 0.1.6 0.1.6 5.88.2 node_modules/webpack demo
