我们维护没有安全漏洞的 package-lock.json 文件的目的是什么？为什么不直接删除它们或者让它们变得陈旧呢？

Question

package-lock.json存储上次运行时安装的所有依赖项和传递依赖项的一组精确版本npm update。我们鼓励您package-lock.json重新提交到您的存储库。

我能找到的唯一真正的消费者package-lock.json是npm ci，它准确地再现了定义的状态package-lock.json，这样您就可以确保您在上次编写的开发机器上的相同依赖项上运行 CI package-lock.json。

另一个用途package-lock.json似乎是产生大量的安全警告。我已经让 Github 的 Dependabot PR-ing 对我提交的package-lock.json文件进行了更改，并抱怨我的package-lock.json文件“发现”了其他无法自动为我修复的漏洞。我怀疑这些无法修复的问题是我的或依赖项中的问题package.json，是由排除有问题模块的固定版本的最大版本要求引起的，但这不是 Dependabot 所说的：

如果package-lock.json仅由 所使用npm ci，那么对那里的过时且易受攻击的软件包版本的引用如何在除我的 CI 系统之外的任何地方创建漏洞？实际安装该软件包的任何人都不会使用它package.json来解决依赖关系，从而在所有漏洞可用时自动修复它们（除非我自己有一个令人讨厌的最大版本限制）？我的存储库的这些 PR 真的只是我和我的所有用户/协作者npm update在我们的机器上运行的建议吗？如果是这样，是什么让 Dependabot 作者通过拉取请求来做到这一点？

如果我package-lock.json从源代码管理中删除，是否可以正确解决package-lock.json- 指示的漏洞（因为该文件不再存在以欺骗某人安装我的依赖项的旧的易受攻击版本）？或者它只会使漏洞扫描器无法扫描我的存储库（即它们是否依赖package-lock.json而不是自行解析依赖项package.json）并使我不知道何时需要npm update？