本文作者:IMWeb 黄qiong 原文出处:IMWeb社区 未经同意,禁止转载
我之前确实对包版本管理这块的知识比较缺失,所以导致我在项目的某次需求当中掉进了很多深坑。这篇文章,希望可以帮助你避开这些包版本管理不善带来的问题。
下面是故事时间:
我们的项目中使用的是preact,preact-compat的库。某天,小A要做需求,时间比较赶所以想引用一些库进来提升效率,但是由于当前preact-compat太低导致不兼容啊。怎么办?这还用问么?当然是升级一下preact-compat的版本啊。
小A开心的就把本地的preact-compat升级了,跑一下本地,很正常嘛,于是就push上了远程愉快的发布了。
发布后不久,产品经理来找小B了,说怎么回事,我们的页面不能用了啊!直接一上来就是遮罩 ,关都关不掉。于是小B赶紧找到发布了需求的小A,问问有没有改到自己的文件。同时也拉取了最新的代码在本地调试。很快就找到了问题 --- 就是由于preact-compat版本升级导致一个JSX-if的库不兼容。原先需要判断一下if else逻辑的地方,一下子全部失效了。
这个故事告诉我们:别以为升级版本是小事,尤其是基础库,你升级的每一个版本,都可能会导致其他页面的问题。所以当需要升级基础库的时候,要确保使用了这个基础库的页面全都是正常运行的。
某个项目组,之前的package.json文件是这样的:
"react": "^15.2.1",
"react-dom": "^15.2.1",
"react-redux": "^5.0.5",
"react-router-dom": "^4.1.2",
"react-router-redux": "^5.0.0-alpha.6",
"redux": "^3.5.2",
"rimraf": "^2.5.4",
"sass-loader": "^6.0.6",
"style-loader": "^0.18.2",
"webpack": "^3.4.1",
"webpack-dev-middleware": "^1.6.1",
"webpack-hot-middleware": "^2.12.2"
看着没啥问题嘛,大家都这样写。但是某天,小A写代码的过程中,发现本地是可以跑的,于是愉快的部署到了服务器系统上,在预发布环境验证的时候,就发现肿么肥事?!页面有个功能用不了了,但是本地明明是没问题的啊?好崩溃。
喝凉水冷静一下。下面是解决思路:
1.本地文件没问题,那我就对比一下部署系统上生成的文件hash值跟本地是否一样不就行了。
2.对比后发现,还真是不一样。为啥本地环境跟部署系统构建出来的文件不一样呢? 3.那一定是本地环境跟部署系统依赖库不同,因为业务代码绝对是一样的啊。 小A于是对比了一下本地跟部署系统上package.json。一毛一样。
但是你知道package.json 里的包版本前面的^代表什么意思么?
包版本可以有三种写法:
"react": "15.2.1"
-- 只匹配一个版本,代表锁死版本,我只下载15.2.1的版本"react": "~15.2.1"
-- 匹配最近的小版本依赖包,比如 ~15.2.1会匹配所有15.2.x的版本,但不包括15.3.0以上,即 >= 15.2.1 && < 15.3.0"react": "^15.2.1"
-- 会匹配最新的大版本依赖包,比如^15.2.1会匹配所有15.x.x的版本,包括15.3.0但是不包括16.0.0,即 >=15.2.1 && < 16.0.0
所以我们的项目中直接所有的库都是^打头的包管理,其实是很有风险的。因为后续发现小B的表现跟部署系统一样,都会报错。
于是在小A跟小B的电脑都跑了一下指令npm ls --deep 0
,看看最终都安装了哪个版本的依赖包。
(不好意思没有小B的电脑,小B安装的是redux@3.8.3,假设吧)
结果发现果然不同,是因为redux的版本不同导致的。
找到问题之后,发现原来在项目中用^又不锁版本,是一件多么危险的事情。 由于环境不同导致安装的依赖包版本不同是很容易发生的。
解决方案
既然是由于版本不一致导致的,那我们就得把项目的依赖包都锁定在一个固定版本。强制大家都安装完全相同的版本依赖。
目前有这两种方案:
1、直接写死版本号,不要加~,^的前缀。
就是我们第一种写法: "react": "15.2.1"
。 但是这样好难维护啊,要时刻盯着官方是不是发了什么版本,fix了什么问题,要靠人来 维护改版本。(反正我们是没有人力来干这个事的,直接抛弃)
2、使用package-lock.json(npm 5.0.0+自带)
不知道大家有没有留意到,每次我们跑npm i
的时候,我们的项目会自动生成一个package-lock.json的文件夹,官方解释如下:https://docs.npmjs.com/files/package-lock.json 简单来说,这个package.json记录了你当前跑npm I的时候,都安装了哪个库的具体版本。 额,我们来瞄一下:
我滴天~~~ 简直不要太详细,连这个包又依赖了哪个库的版本都写的清清楚楚。简直是给赞啊。
我们只需要把这个文件也提交上去部署系统,那么部署系统就会照着这份package-lock.json里面指示的包版本来安装依赖包。
这样就保证了你本地跟部署系统,同时跟其他开发同学的依赖一定是一致的。
妈妈在也不用担心不同环境,不同时间安装依赖的包会不同啦!
最后总结一下吧,两点:
1、升级基础库的时候,一定要注意兼容性,最好使用了这个基础库的页面都过一遍。
2、平时开发过程中要注意提交自动生成的package-lock.json文件锁定版本。