前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >你知道npm包版本管理有多重要么?

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

作者头像
IMWeb前端团队
发布2019-12-03 18:21:33
1.2K0
发布2019-12-03 18:21:33
举报
文章被收录于专栏:IMWeb前端团队

本文作者: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文件是这样的:

代码语言:javascript
复制
   "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文件锁定版本。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2018-12-30 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • 故事一
  • 故事二
    • 下面是三分钟科普时间:
    • 总结
    相关产品与服务
    云服务器
    云服务器(Cloud Virtual Machine,CVM)提供安全可靠的弹性计算服务。 您可以实时扩展或缩减计算资源,适应变化的业务需求,并只需按实际使用的资源计费。使用 CVM 可以极大降低您的软硬件采购成本,简化 IT 运维工作。
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档