不，不应将
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 文件，而
npm ci 仅使用锁定文件中的版本，如果
package-lock.json 和
package.json 不同步，则会产生错误。此外，
npm ci 需要存在一个
package-lock.json，否则会打印出错误信息。在不同机器上可靠地重复解析项目依赖项有很强的用例。此外，
npm ci 在添加依赖项之前会清空整个
node_modules 文件夹，以确保您使用的是实际依赖项，而不是本地更改，同时速度比普通的
npm install 更快。通过
package-lock.json，您可以获得一个已知工作状态，具有完全相同的依赖树。过去，我曾经有一些没有
package-lock.json /
npm-shrinkwrap.json /
yarn.lock 文件的项目，由于随机依赖项进行了破坏性更新，它们的构建会在某一天失败。这些问题很难解决，因为有时您必须猜测最后一个有效版本是哪个。
关于测试项目的最新依赖项：这就是
npm update 的用途，我认为应该由开发人员执行，他们还应该在本地运行测试，解决可能出现的问题，然后提交更改的
package-lock.json。（如果升级失败，可以恢复到上一个工作的
package-lock.json。）
此外，我很少一次性升级所有依赖项（因为这也可能需要进一步的维护），而是选择我需要更新的内容（例如，
npm update {dependency} 或
npm install {dependency}@2.1.3）。这也是为什么我认为它是手动维护步骤的另一个原因。
如果你真的想自动化它，你可以创建一个作业来完成以下任务：
- 检查存储库
- 运行 npm update
- 运行测试
- 如果测试通过，则提交并推送到存储库
- 否则失败并报告问题以手动解决
我认为这应该托管在 CI 服务器上，例如 Jenkins，并且不应该通过将文件添加到
.gitignore 来实现。
或者按照npm文档建议：
强烈建议将生成的包锁提交到源代码控制：这将允许您团队中的任何其他人、您的部署、您的CI/持续集成以及在您的软件包源中运行npm install的任何其他人都能获得与您正在开发的完全相同的依赖项树。此外，这些更改的差异是人类可读的，并将通知您npm对node_modules所做的任何更改，因此您可以注意到是否更新了任何传递依赖项、提升等。
关于npm ci与npm install之间的区别, 请参考以下内容:
- 该项目必须有现有的package-lock.json或npm-shrinkwrap.json。
- 如果包锁中的依赖项与package.json中的依赖项不匹配，则
npm ci将退出错误，而不是更新包锁。
npm ci只能一次安装整个项目：不能使用此命令添加单个依赖项。- 如果已经存在
node_modules，则在npm ci开始安装之前，它将自动删除。
- 它永远不会写入
package.json或任何包锁：安装基本上是冻结的。
