NPM5今天发布，其中一个新特性包括通过创建package-lock.json文件进行确定性安装。
这个文件应该保存在源代码管理中吗？
我假设它类似于yarn.lock和composer.lock，这两个都应该保存在源代码管理中。
是的，package-lock.json打算签入源代码管理。如果您使用的是NPM5+，您可能会在命令行上看到这样的通知:创建了一个锁文件作为package-lock.json。您应该提交此文件。根据npm help package-lock.json:
对于npm修改node_modules树或package.json的任何操作，都会自动生成package-lock.json。它描述了所生成的确切树，以便后续安装能够生成相同的树，而不管中间的依赖项更新如何。
该文件旨在提交到源存储库中，并具有多种用途:
>
描述依赖关系树的单一表示形式，以便保证队友，部署和持续集成安装完全相同的依赖关系。
为用户提供一种工具，使其“时间旅行”到node_modules的以前状态，而不必提交目录本身。
为了便于通过可读的源代码管理来提高树更改的可见性，差异。
并通过允许npm跳过以前安装的包的重复元数据解析来优化安装过程。
关于package-lock.json的一个关键细节是，它不能被发布，如果在顶层包以外的任何地方找到它，它将被忽略。它与npm-shrinkwrapp.json共享一种格式，npm-shrinkwraph.json本质上是同一个文件，但允许发布。除非部署CLI工具或以其他方式使用发布过程生成生产包，否则不建议这样做。
如果package-lock.json和npm-shrinkwrap.json同时存在于包的根中，则将完全忽略package-lock.json。
是的，这是打算登记入住的。我想建议它获得自己唯一的提交。我们发现它给我们的差异增加了很多噪音。
是的，你应该:
包-lock.json。NPM配置项而不是NPM安装NPM CI工作流要求存在package-lock.json。
npm install命令的一个大缺点是它的意外行为，即它可能会改变package-lock.json，而npm ci只使用锁文件中指定的版本并产生错误
package-lock.json和package.json不同步包-lock.json。因此，在本地运行npm install，尤其是。在有多个开发人员的大型团队中，可能会导致package-lock.json内部的许多冲突，而开发人员则决定完全删除package-lock.json。
然而，有一个强大的用例能够信任项目的依赖关系在不同的机器上以可靠的方式重复地解析。
从package-lock.json中，您得到的正是:已知工作状态。
过去，我有一些没有package-lock.json/npm-shrinkwrap.json/yarn.lock文件的项目，这些文件的构建有一天会失败，因为随机依赖项得到了一个突破性的更新。
这些问题很难解决，因为您有时必须猜测上一个工作版本是什么。
如果要添加新的依赖项，仍然运行npm install{dependency}。如果要升级，请使用npm update{dependency}或npm install${dependency}@{version}并提交更改的package-lock.json。
如果升级失败，您可以恢复到上次已知的工作package-lock.json。
要报价npm文档:
强烈建议您将生成的包锁提交给源代码管理:这将允许您的团队，部署，CI/持续集成以及在您的包源中运行npm安装的其他任何人获得与您在其上开发的完全相同的依赖关系树。此外，这些更改的差异是可读的，并将通知您npm对node_modules所做的任何更改，因此您可以注意到是否更新，挂起了任何可传递依赖项等。
关于NPM CI与NPM安装之间的区别:
npm ci将以错误退出，而不是更新包锁。npm ci一次只能安装整个项目:不能使用此命令添加单个依赖项。node_modules已经存在，则在npm配置项开始安装之前将自动删除该配置项。package.json或任何包锁:安装基本上被冻结。注意:我在这里贴了一个类似的答案
