package-lock.json到底是干嘛的？

在npm5里面加入了一个叫package-lock.json的文件，其实从字面意思完全可以get到文件的用处，那就是包锁定，可是当初我升级到5.0的时候完全没有管这个文件，因为觉得既然在这之前没有这个文件都好好的，那不加应该也没事，甚至在gitignore里面直接屏蔽了这个文件的提交。

确实一直都是好好的没有出过什么问题，直到我在上次打包时手动remove了node_modules文件夹，再重新npm install了依赖，照理说确实不会出现问题的。可是上线后运营反馈一个组件在360下不好使。对比后才发现我install了该组件2版本下的最新版本，2.7.1，可是测试环境是2.5.1，翻看官方的releases，并没有找到兼容性问题的提及，

所以还是初步怀疑应该是新版本导致的bug，于是我只能手动指定版本再次安装依赖后再打包，问题好像解决了。痛定思痛，我决定好好研究下package-lock.json这个文件在新版本里到底起了什么作用。

其实用一句话来概括很简单，就是锁定安装时的包的版本号，并且需要上传到git，以保证其他人在npm install时大家的依赖能保证一致。

引用知乎@周载南的回答

根据官方文档，这个package-lock.json 是在 `npm install`时候生成一份文件，用以记录当前状态下实际安装的各个npm package的具体来源和版本号。

它有什么用呢？因为npm是一个用于管理package之间依赖关系的管理器，它允许开发者在pacakge.json中间标出自己项目对npm各库包的依赖。你可以选择以如下方式来标明自己所需要库包的版本

这里举个例子：

"dependencies": {

"@types/node": "^8.0.33",

},

这里面的 向上标号^是定义了向后（新）兼容依赖，指如果 types/node的版本是超过8.0.33，并在大版本号（8）上相同，就允许下载最新版本的 types/node库包，例如实际上可能运行npm install时候下载的具体版本是8.0.35。波浪号

大多数情况这种向新兼容依赖下载最新库包的时候都没有问题，可是因为npm是开源世界，各库包的版本语义可能并不相同，有的库包开发者并不遵守严格这一原则：相同大版本号的同一个库包，其接口符合兼容要求。这时候用户就很头疼了：在完全相同的一个nodejs的代码库，在不同时间或者不同npm下载源之下，下到的各依赖库包版本可能有所不同，因此其依赖库包行为特征也不同有时候甚至完全不兼容。

因此npm最新的版本就开始提供自动生成package-lock.json功能，为的是让开发者知道只要你保存了源文件，到一个新的机器上、或者新的下载源，只要按照这个package-lock.json所标示的具体版本下载依赖库包，就能确保所有库包与你上次安装的完全一样。

原来package.json文件只能锁定大版本，也就是版本号的第一位，并不能锁定后面的小版本，你每次npm install都是拉取的该大版本下的最新的版本，为了稳定性考虑我们几乎是不敢随意升级依赖包的，这将导致多出来很多工作量，测试/适配等，所以package-lock.json文件出来了，当你每次安装一个依赖的时候就锁定在你安装的这个版本。

那如果我们安装时的包有bug，后面需要更新怎么办？

在以前可能就是直接改package.json里面的版本，然后再npm install了，但是5版本后就不支持这样做了，因为版本已经锁定在package-lock.json里了，所以我们只能npm install xxx@x.x.x 这样去更新我们的依赖，然后package-lock.json也能随之更新。

假如我已经安装了jquery 2.1.4这个版本，从git更新了package.json和package-lock.json，我npm install能覆盖掉node_modules里面的依赖吗?

其实我也有这个疑问，所以做了测试，在直接更新package.json和package-loc.json这两个文件后，npm install是可以直接覆盖掉原先的版本的，所以在协作开发时，这两个文件如果有更新，你的开发环境应该npm install一下才对。

写在最后

本次故障，其实早就埋下了祸根，因为我的不规范操作：打包系统不同（我们是在本地打包的），打包源不同。严格的流程应该是保证测试环境环境和生产环境的：

操作系统一致

版本号一直

打包代码一直

运行依赖一致

运行环境一直

...

这样才能尽可能的保证测试的结果能够保证和可靠，避免出现测试后bug在生产环境在线的可能。