不，
package-lock.json不 应该添加到中
.gitignore。相反，我强烈建议：
- 将
package-lock.json
您添加到版本控制存储库 npm ci``npm install
在本地和部署管道中构建应用程序时， 请使用 代替 。
（该ci
命令自npm@5.7起可用，如有疑问，请通过以下方式升级npm ：）npm install -g npm
。
该
npm install命令最大的缺点之一是它的意外行为，它可能会使突变
package-lock.json，而
npmci仅在锁文件中使用该版本，如果
package-lock.json和
package.json不同步，则会产生错误。
另外，
npm ci要求 存在a
package-lock.json，如果不存在则会打印错误。有一个强大的用例，可以信任该项目的依赖项可以在不同机器上以可靠的方式重复解决。
此外，在添加依赖项之前先
npmci对整个
node_modules文件夹进行修改，以确保您使用实际的依赖项（而不是本地更改），同时仍比普通的要快
npm install。
从中
package-lock.json您可以确切地得到：一个已知的工作状态。
过去，我有没有
package-lock.json/
npm-shrinkwrap.json/
yarn.lock文件的项目，由于随机依赖项的最新更新，其构建将有一天失败。（尽管许多库都遵循semvar版本控制指南，但不能保证它们在进行较小的升级时不会中断。）
这些问题很难解决，因为您有时不得不猜测最新的工作版本是什么。
关于测试项目的最新依赖关系：这是
npmupdate为了解决这个问题，我认为它应该由开发人员运行，该开发人员还要在本地运行测试，如果可能出现问题，则应解决问题，然后提交更改
package-lock.json。（如果升级失败，他们可以恢复到上一个工作状态
package-lock.json。）
此外，我很少一次升级所有依赖项（因为这也可能需要进一步维护），但我宁愿选择需要的更新（例如
npm update {dependency}或npminstall {dependency}@2.1.3）。这是我将其视为手动维护步骤的另一个原因。如果您真的想让它自动化，可以为以下项目创建工作：
- 结帐库
- 运行npm更新
- 运行测试
- 如果测试通过，则提交并推送到存储库
- 否则失败并报告问题，以手动解决
我将看到这是托管在CI服务器（例如Jenkins）上的东西，不应通过将文件添加到的上述原因来实现
.gitignore。
或引用npm doc：
强烈建议您将生成的程序包锁定提交给源代码控制：这将允许您团队中的其他任何人，您的部署，您的CI
/持续集成以及在包源中运行npm的其他任何人都可以在程序包源中获得完全相同的依赖关系树你在继续发展。此外，这些更改的差异是人类可读的，并且会通知您npm对您的node_modules所做的任何更改，因此您可以注意到是否有任何传递性依赖项被更新，提升等。
并且关于vs 之间
npm ci``npminstall的区别：
- 该项目必须具有现有的package-lock.json或npm-shrinkwrap.json。
- 如果包锁中的依赖项与package.json中的依赖项不匹配，
npm ci则将退出并显示错误，而不是更新包锁。- 如果
node_modules已经存在，它将在npm ci开始安装之前被自动删除。- 它永远不会写入
package.json或执行任何程序包锁定：安装实际上是冻结的。
