npm版本管理

最新推荐文章于 2025-05-23 16:27:09 发布

weixin_34087307

最新推荐文章于 2025-05-23 16:27:09 发布

阅读量343

点赞数

CC 4.0 BY-SA版权

文章标签： json javascript ui ViewUI

原文链接：https://juejin.im/post/5acc348f518825558a06ef3d

本文介绍了NPM中版本号的管理方式，并详细解释了如何使用~和^符号来指定依赖包版本范围。同时，文章还探讨了package-lock.json文件的作用及如何正确地更新依赖。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Npm根据X.Y.Z来管理版本号 X代表主版本 Y代表次要版本 Z代表bug修复，UI视觉修复。不是10进制，不进位。 X.Y的区别。一般Z的很好区别，主要看是否有bug修复。如果一个新需求，如何确定版本：主要看是否破坏了现有代码的结构。如果没有破坏，用Y，否则用X. 例如原来代码如下

export  {
    getDate:function(){}
}

复制代码

export {
	TimeUtil:{
	getDate:function(){}
     }
  }

export {
	getDate:function(){},
	log:function(){}
}
复制代码

第2种多了TimeUtil破坏了原来的代码结构，就用主版本。

第三种多了一个log但没有影响原来的结构，只是增量，用次版本。

具体看下图。

上面是发版的规则，下面是使用的规则。

tilde（~): 只影响第三位，用于bug修复。

~1.2.3 会自动匹配到1.2.x如1.2.10，而不会匹配1.3.0。

caret (^): 影响Y.Z，对原有功能不破坏。

^1.2.3会自动匹配1.x.x如1.10.10,而不会匹配2.0.0

目前用的最多的就是^这种模式，因为^匹配Y.Z，Y新功能不影响原有功能，Z只负责bugfix，所以基本上就是一个增量。其他的模式还是Node.js 项目依赖管理

虽然懂得很多道理，仍然管不好版本。

具体表现为

1. npm仓库的某个版本已经是1.9.0，本地的package.json的版本范围为^1.8.0 按道理是可以直接升级的，但是死活升级不了。这个主要原因是npm从5.0版本之后以package-lock.json里面的版本为主。

2. 还有碰到的问题是我锁死了自己的依赖，但是内部依赖更新了。之前碰到的一个问题是用了autoprefixer，但是它内部升级了caniuse-db，导致构建失败。

3. 自己下了比如lodash2.7.2,package.json配置为^2.7.2,过了断时间，lodash升级了2.8.0,别的同事一安装就报错，查半天也查不到这个问题在哪里。

所以package-lock.json的引入就是为了解决了上面问题，他会精确列出所有的依赖，指定特定版本。

有些人碰到上面的问题之后，会直接删了package-lock.json 然后npm install。这个确实会解决升级的问题，但是又带来了一个更大的隐藏问题: 所有的内部依赖都会升级，你就会碰到上面提到的第二种情况。

npm文档指出任何修改了package.json和node_modules的改动，都会自动同步package-lock.json。这些操作包括npm install,npm update,npm rm.

因此，下次升级版本直接用npm install —save lodash@2.7.5或者npm install —save mypackage@latest，可以看到package.json和package-lock.json都更新了。

这样既更新了版本，又保持了各个环境依赖版本的一致性。

因此，如果没有升级到npm5（node 8）尽快升级到5，可以享受新功能带来的好处。

我们是否应该在gitignore里面忽略package-lock.json?

转载于:https://juejin.im/post/5acc348f518825558a06ef3d