当你开心的将npm升到v5.x.x(原文时代)以后，一切都彷佛还挺顺利。诶…等等，一个新文件被自动建立啦！这是啥？Package-lock.json。若是你有浏览它，会发现它长得相似package.json的依赖，可是冗长多啦。你想，干脆无论它得了，但是最后老是会碰见关于依赖装错版本或者找不到依赖等等各式各样的问题。许多人的解决方式都是删掉package-lock.json，再跑一遍npm install。如果如此，package-lock.json存在的意义是啥？它的目的又是为了解决什么呢？html
在一探package-lock究竟以前，你必需要理解semver。它是npm背后的小小功臣。你能够从这里了解到npm是如何使用它的。归纳来说，倘若你在开发一个可供其它应用使用的应用，你必须说明每次升级变动会对第三方使用产生哪些影响。这就是语义化版本想要传达的。一个版本有三部分：X, Y, Z，分别指代大版本，小版本，与查缺补漏版本。好比1.2.3，那么就是大版本1，小版本2，bugfix版本3。bugfix版本不会影响任何功能，小版本变动每每是增长新功能，也不会影响使用。而大版本变动每每会带来使用层面不兼容的状况，须要再作调整。（想一想webpack每次升级的时候！）webpack
正是为了让包管理变简单，npm出现了。一个项目可能有上百个依赖，每一个依赖又有上百个依赖。为了你不陷入依赖地狱，只需简单几行命令，npm就能够安装并管理这些依赖，大大节省了时间。git
当你使用npm安装一个包(并保存它)的时候，package.json里就自动添加了一条信息，包括包名和其版本。npm固然也支持版本的通配符。npm默认安装最新版本，而后在其版本号以前添加一个"^"符。好比“^1.2.12”，它代表最低应使用1.2.12版本，而且在这之上，拥有相同大版本号的任何版本都是OK的。毕竟小版本和bugfix版本不会对使用形成任何影响，因此用任何相同大版本的更高级版本都很安全。能够从这里了解semver通配符的更多信息，以及npm的semver计算器。github
Package.json的真正好处在于，任何人均可以经过这个文件生成一个装有项目所需全部依赖的文件夹。可是咱们来看一下，哪些地方可能出问题呢？web
就来新建一个使用express的项目吧。执行npm init后，安装express:npm install express — save。我撰文时express最高版本是4.15.4。因此“express”: “^4.15.4”被写进package.json里，依赖也已经装好了。不过次日，可能express的维护者发布了一个bugfix版本，因此最新版本又变成了4.15.5。若是这时我同事clone了这个项目，而且执行npm install，由于4.15.5的大版本号没变，因此他装的版本就会是最新的4.15.5。咱们都安装了express，不过是不一样的版本。按道理讲他们是互相兼容的，可是可能好巧不巧，这个被修复的bugfix恰好就影响到咱们使用的功能了，那么咱们分别运行本身的项目时就会出现不一样的结果。这是个问题！express
Package-lock的出现就是为了解决上述问题的！也就是从同一份package.json文件可能安装出不同的结果。Package-lock.json自npm 5.x.x后加入，因此只要你没禁止掉它（注：能够从.npmrc设置package-lock = false喔），它都会自动生成。npm
Package-lock包括package.json里所例举的包的应安装版本，安装地址(URI)，校验包完整性的hash，其须要的子包，以及依赖列表。express的package-lock条目以下：json
"express": {
"version": "4.15.4",
"resolved": "https://registry.npmjs.org/express/-/express-4.15.4.tgz",
"integrity": "sha1-Ay4iU0ic+PzgJma+yj0R7XotrtE=",
"requires": {
"accepts": "1.3.3",
"array-flatten": "1.1.1",
"content-disposition": "0.5.2",
"content-type": "1.0.2",
"cookie": "0.3.1",
"cookie-signature": "1.0.6",
"debug": "2.6.8",
"depd": "1.1.1",
"encodeurl": "1.0.1",
"escape-html": "1.0.3",
"etag": "1.8.0",
"finalhandler": "1.0.4",
"fresh": "0.5.0",
"merge-descriptors": "1.0.1",
"methods": "1.1.2",
"on-finished": "2.3.0",
"parseurl": "1.3.1",
"path-to-regexp": "0.1.7",
"proxy-addr": "1.1.5",
"qs": "6.5.0",
"range-parser": "1.2.0",
"send": "0.15.4",
"serve-static": "1.12.4",
"setprototypeof": "1.0.3",
"statuses": "1.3.1",
"type-is": "1.6.15",
"utils-merge": "1.0.0",
"vary": "1.1.1"
}
},
requires下例举的每一个包，都在package-lock下拥有一份一样的条目。安全
因此npm其实如今是用package-lock.json来决定如何安装依赖的！由于package-lock写明了包的安装版本，地址，也作了包完整性校验，以及例举了包的全部子依赖，因此按照package-lock来装模块的话，必定会获得如出一辙的结果。cookie
既然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日起即日执行~