package-lock.json简介

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

以上摘自官方文档，义译一下就是

package-lock.json会在npm更改node_modules目录树或者package.json时自动生成的。它准确的描述了当前项目npm包的依赖树，并且在随后的安装中会根据package-lock.json来安装，保证是相同的一个依赖树，不考虑这个过程中是否有某个依赖有小版本的更新。

这里有个很重要的点就是，package-lock.json记录的是一个依赖树，而不是你直接在package.json中的依赖项。和直接在package.json中锁死版本不一样的地方在于，package.json中只是锁死了依赖项的版本，而没有锁死依赖项的依赖的版本，这里就是变数的地方。如果不对整个依赖树做锁定，那前后编译出来的应用版本可能是不一样的，有可能开发时能正常工作，而到了线上却不能工作。

所以很明显的package-lock.json是很符合我们的诉求的。我们需要让后面每一次install都是相同的版本，打出来的包都有着相同的依赖，这对于我们项目的稳定性、前后一致性是非常重要的。

如何解决package-lock的冲突呢？

不要试图删除package-lock.json来解决一些问题，这样会破坏package-lock.json的作用。

package-lock是工具自动生成的一个文件内容，对于这种自动生成的文件最好的办法还是交由工具去处理，而不是手工一个一个的去处理产生的冲突。

在开发过程中，合并的时候如何如果出现了冲突，在merge conflicts的阶段，只需要从主分支中checkout去package-lock.json，再以此为基础，重新安装新分支中需要的依赖。

git checkout dev -- package-lock.json;
npm install lodash --save;

这样让npm自动的去维护package-lock.json。当然上面的步骤同样也适用于rebase过程。

我相信这个办法可以很好的解决package-lock.json冲突的问题，并且团队合作中，做merge或者rebase操作的人可以通过查看package.json的变更知道新安装了哪些依赖包，来重新安装，也可以很好的解决这个问题。

校验package-lock.json的正确性

在按照上面的步骤解决完package-lock.json的冲突后，code reviewer对package-lock.json的正确性需要做一次校验，按照gerrit中的说法就是verify的过程。将被review的代码拉到本地做一次npm install，检查package-lock.json是否有modified，如果没有modify说明提交的package-lock.json是一份正确的文件。

有一个问题，package-lock.json中的resolved字段会被不同环境中的npm registry改写，这样会导致很多的冲突。所以在经过正确性校验的过程中，可能会因为本地registry的配置问题会导致package-lock.json处于modified状态。所以为了规避这个问题，需要在团队内统一npm registry，可以在项目根目录中使用.npmrc来配置项目级别的registry来进行统一。