共计 2285 个字符，预计需要花费 6 分钟才能阅读完成。
前言
我之前的确对包版本治理这块的常识比拟缺失，所以导致我在我的项目的某次需要当中掉进了很多深坑。这篇文章，心愿能够帮忙你避开这些包版本治理不善带来的问题。
上面是故事工夫：
故事一
咱们的我的项目中应用的是 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.json 记录了你以后跑 npm I 的时候，都装置了哪个库的具体版本。额，咱们来瞄一下：
我滴天~~~ 几乎不要太具体，连这个包又依赖了哪个库的版本都写的清清楚楚。几乎是给赞啊。
咱们只须要把这个文件也提交下来部署零碎，那么部署零碎就会照着这份 package-lock.json 外面批示的包版本来装置依赖包。
这样就保障了你本地跟部署零碎，同时跟其余开发同学的依赖肯定是统一的。
妈妈在也不必放心不同环境，不同工夫装置依赖的包会不同啦！
总结
最初总结一下吧，两点：
1、降级根底库的时候，肯定要留神兼容性，最好应用了这个根底库的页面都过一遍。
2、平时开发过程中要留神提交主动生成的 package-lock.json 文件锁定版本。
