前言

平常开发过程中我们肯定遇到过，自己本地启动没啥问题，但是同事install依赖就跑不起来或打包发布到线上运行失败，这个问题很可能就是某依赖版本号不一致导致的，这个问题一般可以通过package-lock.json锁定依赖版本来解决，保障开发和生产环境一致。

package-lock.json 在执行 npm i 的时候生成，用来记录实际安装的 npm 包的来源和版本。可以锁定安装时的包的版本，需要上传到 git，确保大家使用的包版本一致。

概览

1. 如果你用的是npm 5.0.0以上版本，package-lock.json文件会自动创建。
2. package-lock被用来确保稳定安装和依赖兼容。
3. 为确保源一致，你必须提交package-lock文件。
4. npm 5.1.x以上版本，package.json的权重大于package-lock.json，解决了一大头疼源泉。
5. 不用手动删去package-lock文件然后再npm install再重新生成它啦。
6. 使用并遵循semver语义化版本。

semver语义化版本

在一探package-lock究竟之前，你必须要理解semver。它是npm背后的小小功臣。你可以从这里了解到npm是如何使用它的。概括来讲，假若你在开发一个可供其它应用使用的应用，你必须说明每次升级变更会对第三方使用产生哪些影响。这就是语义化版本想要传达的。一个版本有三部分：X, Y, Z，分别指代大版本，小版本，与查缺补漏版本。比如1.2.3，那么就是大版本1，小版本2，bugfix版本3。bugfix版本不会影响任何功能，小版本变更往往是增加新功能，也不会影响使用。而大版本变更往往会带来使用层面不兼容的情况，需要再做调整。

实践场景1

假设刚从远程仓库克隆一个项目，此时本地 node_modules 还不存在，package.json 和 package-lock.json 如下。已知 superagent 3.x.x 的最新版本是 3.8.3，那么运行 npm install 是根据 package-lock.json 中指定的版本 3.5.1 下载还是根据 package.json 去下载最新的 3.x.x ？

// package.json
"dependencies": {
    "superagent": "^3.5.1"
}

// package-lock.json
{
  "superagent": {
      "version": "3.5.1",
      "resolved": "https://npm.garenanow.com/superagent/-/superagent-3.5.1.tgz",
      "integrity": "sha1-Ck+u/aM2d3d4iDR917TSH0EMhxs=",
      "requires": {
        "component-emitter": "^1.2.0",
        "cookiejar": "^2.0.6",
        "debug": "^2.2.0",
        "extend": "^3.0.0",
        "form-data": "^2.1.1",
        "formidable": "^1.1.1",
        "methods": "^1.1.1",
        "mime": "^1.3.4",
        "qs": "^6.1.0",
        "readable-stream": "^2.0.5"
      }
    },
}

结论：下载的是 3.5.1。此时 package.json 和 package-lock.json 同时存在，package.json 的 version 是 ^3.5.1，package-lock.json 的 version 是 3.5.1，并且当前 node_modules 中下载的也是 3.5.1

实践场景2

接着场景1，然后手动修改 package.json 中 superagent 的版本为 ^5.1.0，再执行 npm i，发现不管有没有删除已有的 node_modules，package-lock.json 中 superagent 的版本都变成了 5.1.0，node_modules 中的也变成了 5.1.0

总结

既然packge-lock是用来解决问题的，那为什么还有许多质疑它存在，以及关于如何禁止它生成的讨论呢？ npm5.x.x以前，package.json是项目的唯一真理来源。package.json说啥就是啥！npm使用者喜欢并习惯仅维护package.json。但是，当package-lock出现后，它和很多人期望的背道而驰了！如果有同一份package和package-lock，package.json的修改并不会影响到package-lock。 于是就出现了更改package.json后，安装未生效的情况，需要移除package-lock再生成一份，由此引发了很多争论。可以从这份有趣的reop时间线上看出端倪。有的人觉得还是得以package.json为准，有的人又觉得既然package-lock被创造出来了，那就以新的为准呗。最后这份争论以PR#17508划上句号。npm决定，如果package.json上发生过改动，安装时package.json的权重就会超过package-lock。这个决定随着npm v5.1.0发布，自2017年7月5日起即日执行。实践场景2就验证了这个，大家感兴趣的话可以私下去研究下。