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

前言

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

下面是故事时间：

故事一

我们的项目中使用的是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，看看最终都安装了哪个版本的依赖包。

  

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

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

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

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

总结

最后总结一下吧，两点：

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

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