转载至 ：https://zhuanlan.zhihu.com/p/53652105
你知道npm包版本管理有多重要么？
daisy
daisy
前言
喝了一杯星巴克，一晚上都睡不着，终于有空写篇文章。
我之前确实对包版本管理这块的知识比较缺失，所以导致我在项目的某次需求当中掉进了很多深坑。这篇文章，希望可以帮助你避开这些包版本管理不善带来的问题。
下面是故事时间：
故事一
我们的项目中使用的是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。一毛一样。
都长这样，妥妥的：
"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"
但是你知道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安装的是[email protected]，其他都一样，假设吧）
结果发现果然不同，是因为redux的版本不同导致的。
找到问题之后，发现原来在项目中用^又不锁版本，是一件多么危险的事情。 由于不同环境、不同时间，导致安装的依赖包版本不同是很容易发生的。
解决方案
既然是由于版本不一致导致的，那我们就得把项目的依赖包都锁定在一个固定版本。强制大家都安装完全相同的版本依赖。
目前有这两种方案：
- 直接写死版本号，不要加~,^的前缀
就是我们第一种写法： “react”: “15.2.1”。 但是这样好难维护啊，要时刻盯着官方是不是发了什么版本，fix了什么问题，要靠人力来维护改版本。（反正我们是没有人力来干这个事的，直接抛弃这种方案）
2.使用package-lock.json（npm 5.0.0+自带）
不知道大家有没有留意到，每次我们跑npm i的时候，我们的项目会自动生成一个package-lock.json的文件夹，官方解释如下。
简单来说，这个package-lock.json记录了你当前跑npm i的时候，都安装了哪个库的具体版本。 额，我们来瞄一下：
我滴天~~~ 简直不要太详细，连这个包又依赖了哪个库的版本都写的清清楚楚。简直是赞啊。
我们只需要把这个文件也提交上去部署系统，那么部署系统就会照着这份package-lock.json里面指示的包版本来安装依赖包。
这样就保证了你本地跟部署系统，同时跟其他开发同学的依赖一定是一致的。
妈妈在也不用担心不同环境，不同时间安装依赖的包会不同啦！
总结
最后总结一下吧，两点：
1、升级基础库的时候，一定要注意兼容性，最好使用了这个基础库的页面都过一遍。
2、平时开发过程中要注意提交自动生成的package-lock.json文件锁定版本。