这个问题在这里已有答案：
要锁定在项目上安装的依赖项版本，命令npm install会创建一个名为package-lock.json的文件。这是自Node.js v8.0.0和npm v5.0.0以来你们可能知道的。
尽管有Node.js和npm关于提交此文件的建议，但是关于何时应该避免这样做的几个问题也是一种选择。通常我们在项目中承诺，但这是一个特殊的问题。
虽然我们应该默认提交package-lock.json文件，但我们有一个特定的情况我们不应该这样做。例如，如果我们想测试项目依赖项的最新版本，可以选择将package-lock.json添加到.gitignore中。
所以，问题如下：
package-lock.json文件应该添加到.gitignore吗？不，package-lock.json不应该添加到.gitignore。相反，我强烈建议：
您应该将package-lock.json添加到版本控制存储库中。
我还建议在构建应用程序时使用npm ci而不是npm install，并且该工作流程需要存在package-lock.json。 （npm install命令最大的缺点之一是它可能会改变package-lock.json，而npm ci只使用lockfile中的版本并且如果package-lock.json和package.json不同步则会产生错误。）
有一个强大的用例，可以相信项目的依赖关系可以在不同的机器上以可靠的方式重复解决。
从package-lock.json你可以得到：一个已知的工作状态。
在过去，我有没有package-lock.json / npm-shrinkwrap.json / yarn.lock文件的项目，其构建将失败一天，因为随机依赖得到了更新。
这些问题很难解决，因为你有时不得不猜测最后一个工作版本是什么。
关于测试项目的最新依赖项：这就是npm update的用途，我认为它应该由开发人员运行，开发人员也在本地运行测试，如果出现问题则解决问题，然后谁提交更改package-lock.json。 （如果升级失败，他们可以恢复到最后一个工作的package-lock.json。）
此外，我很少一次升级所有依赖项（因为这也可能需要进一步维护）但我更喜欢挑选我需要的更新。这是我将其视为手动维护步骤的另一个原因。
如果您想让它自动化，您可以创建一份工作：
这是我在CI服务器上托管的内容，例如詹金斯，它不应该通过上述原因通过将文件添加到.gitignore来实现。
或者到quote npm doc：
强烈建议您将生成的包锁提交给源代码控制：这将允许团队中的其他任何人，您的部署，CI /持续集成以及在您的包源中运行npm install的任何其他人获得完全相同的依赖关系树你正在开发的。此外，这些更改的差异是人类可读的，并将告知您npm对node_modules所做的任何更改，因此您可以注意到是否有任何传递依赖项已更新，提升等。
关于difference between npm ci vs npm install：
- 该项目必须具有现有的package-lock.json或npm-shrinkwrap.json。
- 如果包锁中的依赖项与package.json中的依赖项不匹配，则
npm ci将退出并显示错误，而不是更新包锁。npm ci一次只能安装整个项目：使用此命令无法添加单个依赖项。- 如果
node_modules已经存在，它将在npm ci开始安装之前自动删除。- 它永远不会写入
package.json或任何包锁：安装基本上是冻结的。