nodejs依赖版本管理遇到的问题

这是shrinkwrap的文档,讲了这个工具能做什么:https://docs.npmjs.com/cli/shrinkwrap

为何要用shrinkwrap?

因为当你用了好几个nodejs库作为你项目的依赖后,不同开发人员在使用时可能会装上不同版本的库,从而导致有些奇怪的问题,例如在我这里是这样的,在他那里又变成另外一个样子了。

一开始我们装了一些库,默认npm给我们用了这样的版本:"^1.0.0",在大于1.0.0的版本时,caret(也就是这个符号^)会控制住major版本不变,可以升级minor和patch。那么当我今天npm install的时候可能装了个1.0.0的版本,但一个月之后,一个新同事来再执行npm install时可能得到1.2.0的版本。

我们觉得这样不好,于是项目依赖的版本都写成了固定的,比如1.2.3,这样谁来装都会装上1.2.3的库,再固定由一个人或者隔一段时间升级这些依赖,到时候大家再安装的时候也会升级。看来问题已经解决了。

当然不是。

虽然我们都装了1.2.3的库,但这个库也有自己的依赖,例如这个1.2.3版本的库依赖了一个库,那个库的版本限制是"^2.0.0",呵呵,又可能出现不同时间装同一个版本的库出现的些许不一致,例如我和同事都装的同一个版本的watchify库,但watchify库的依赖isarray我用的是0.0.1,同事的就是1.0.0,当我删掉整个node modules后重装就一致了。真是坑人啊!

后来发现了shrinkwrap这个工具,可以完全确定你的依赖和你依赖的依赖和你依赖的依赖的依赖……的版本,总之用了这个后所有库的版本都确定了,在npm install的时候,会优先查找有没有shrinkwrap生成的文件,如果有就用这个,而不是package.json了。

又清净了。

这个问题探索的时候还有些疑虑——nodejs的第三方库为何写的依赖都是开放性的,例如"^1.0.0"这样,因为你这样写了,所以别人在用的时候有可能给装上一个1.2.3的依赖,有可能给装上一个1.4.5的依赖,如果确实都测试了1.2.3和1.4.5甚至一直到1.9.x都没有break你的使用(我觉得那是不可能的),那完全可以写"^1.0.0",实际情况不造,但我觉得这些项目是完全没有精力做这些测试的。当你懒惰了一下,把你作为依赖的别人可能就会很难受。

另外就是,能够升级依赖到最新版有好处,性能提升、bug fix等,不过因为版本那么开放,实在不敢直接就升级上去啊。