你知道npm包版本管理有多重要么?

MarjoryDaphne 发布于7月前
0 条问题

前言

我之前确实对包版本管理这块的知识比较缺失,所以导致我在项目的某次需求当中掉进了很多深坑。这篇文章,希望可以帮助你避开这些包版本管理不善带来的问题。

下面是故事时间:

故事一

我们的项目中使用的是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写代码的过程中,发现本地是可以跑的,于是愉快的部署到了服务器系统上,在预发布环境验证的时候,就发现肿么肥事?!页面有个功能用不了了,但是本地明明是没问题的啊?好崩溃。

你知道npm包版本管理有多重要么?

喝凉水冷静一下。下面是解决思路:

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 ,看看最终都安装了哪个版本的依赖包。

    你知道npm包版本管理有多重要么?

    (不好意思没有小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的时候,都安装了哪个库的具体版本。 额,我们来瞄一下: 你知道npm包版本管理有多重要么?

我滴天~~~ 简直不要太详细,连这个包又依赖了哪个库的版本都写的清清楚楚。简直是给赞啊。

我们只需要把这个文件也提交上去部署系统,那么部署系统就会照着这份package-lock.json里面指示的包版本来安装依赖包。

这样就保证了你本地跟部署系统,同时跟其他开发同学的依赖一定是一致的。

你知道npm包版本管理有多重要么?

妈妈在也不用担心不同环境,不同时间安装依赖的包会不同啦!

总结

最后总结一下吧,两点:

1、升级基础库的时候,一定要注意兼容性,最好使用了这个基础库的页面都过一遍。

2、平时开发过程中要注意提交自动生成的package-lock.json文件锁定版本。

查看原文: 你知道npm包版本管理有多重要么?

  • brownkoala
  • greenwolf
  • heavykoala
  • beautifulsnake
需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。