package-lock.json为上次运行时安装的所有依赖项和传递依赖项存储一组精确版本npm update。我们鼓励您重新提交package-lock.json您的回购协议。
package-lock.json我能找到的唯一真正的消费者是npm ci，它精确地再现了定义的状态，package-lock.json这样您就可以确定您在与上次编写的开发机器上相同的依赖项上运行 CI package-lock.json。
另一件事package-lock.json似乎用于产生大量的安全警告。我已经对我提交的package-lock.json文件进行了 Github 的 Dependabot PR-ing 更改，并抱怨我package-lock.json是它“发现”其他无法为我自动修复的漏洞的地方。我怀疑这些无法修复的问题是 my 或依赖项中的问题package.json，由排除有问题模块的固定版本的最大版本要求引起，但这不是 Dependabot 所说的：
如果package-lock.json仅由 使用npm ci，那么对那里的包的过时且易受攻击的版本的引用如何在我的 CI 系统之外的任何地方创建漏洞？实际安装软件包的人不会使用package.json来解决依赖关系，从而在所有漏洞可用时自动修复它们（除非我自己有一个令人讨厌的最大版本限制）？这些对我的 repo 的 PR 真的只是建议我和我的所有用户/合作者npm update在我们的机器上运行吗？如果是这样，是什么让 Dependabot 作者通过拉取请求来做到这一点？
如果我package-lock.json从源代码控制中删除，这是否会正确解决package-lock.json-indiced 漏洞（因为该文件不再存在以欺骗某人安装我的依赖项的旧易受攻击版本）？或者它只会使漏洞扫描程序无法扫描我的存储库（即他们是否依赖package-lock.json而不是自己解决依赖关系package.json）并使我不知道何时需要npm update？