不，package-lock.json不应该添加到.gitignore中。相反，我强烈建议:

1. 将package-lock.json添加到您的版本控制存储库
2. 在本地和部署管道中构建应用程序时，使用npm ci而不是npm install。
   (ci命令从npm@5.7开始可用，如果有疑问，请通过:
   npm install-g npm升级npm.）

npm install命令最大的缺点之一是它的意外行为，即它可能会改变package-lock.json，而npm ci只使用锁文件中的版本，如果package-lock.json和package.json不同步，则会产生错误。

另外，npmci要求存在package-lock.json，如果不存在，则会打印错误。有一个强大的用例能够信任项目的依赖关系在不同的机器上以可靠的方式重复地解析。

此外，npmci在添加依赖项之前会对整个node_modules文件夹进行核爆炸，以确保您使用的是实际的依赖项而不是本地更改，同时仍然比正常的npm安装更快。

从package-lock.json中，您得到的正是:已知工作状态。

过去，我有一些没有package-lock.json/npm-shrinkwrap.json/yarn.lock文件的项目，这些文件的构建有一天会失败，因为随机依赖项得到了一个突破性的更新。（虽然许多库都遵守semvar版本控制准则，但您不能保证它们不会在一次小升级中中断。）

这些问题很难解决，因为您有时必须猜测上一个工作版本是什么。

关于测试项目的最新依赖项:这就是npm update的作用，我认为它应该由开发人员运行，开发人员也在本地运行测试，解决可能出现的问题，然后提交更改后的package-lock.json。（如果升级失败，它们可以恢复到上次工作的package-lock.json。）

此外，我很少一次升级所有依赖项（因为这也可能需要进一步的维护），而是选择我需要的更新（例如npm update{dependency}或npm install{dependency}@2.1.3)。这也是我将其视为手动维护步骤的另一个原因。

如果您真的想让它自动化，您可以为以下项目创建一个作业:

• 签出存储库
• 运行npm更新
• 运行测试
  • 如果测试通过，则提交并推送到存储库
  • else失败并报告要手动解决的问题

  这是我在CI服务器（例如Jenkins）上看到的，不应该通过将文件添加到.gitignore中的上述原因来实现。

  或引用npm文档:

  强烈建议您将生成的包锁提交给源代码管理:这将允许您的团队，部署，CI/持续集成以及在您的包源中运行npm安装的其他任何人获得与您在其上开发的完全相同的依赖关系树。此外，这些更改的差异是可读的，并将通知您npm对node_modules所做的任何更改，因此您可以注意到是否更新，挂起了任何可传递依赖项等。

  关于NPM CI与NPM安装之间的区别:

  • 项目必须有一个现有的包-lock.json或npm-shrinkwrapp.json.
  • 如果包锁中的依赖项与package.json中的依赖项不匹配，npm ci将以错误退出，而不是更新包锁。
  • npm ci一次只能安装整个项目:不能使用此命令添加单个依赖项。
  • 如果node_modules已经存在，则在npm配置项开始安装之前将自动删除该配置项。
  • 它永远不会写入package.json或任何包锁:安装基本上被冻结。