对于那些抱怨做gitdiff时噪音的人：

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

我所做的是使用别名：

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

要忽略整个存储库（每个人都使用它）diffs中的package-lock.json，可以将其添加到.gitattributes中：

package-lock.json binary
yarn.lock binary

这将导致diff显示“每当包锁定文件更改时，二进制文件a/package-lock.json和b/package-llock.json都不同。此外，一些Git服务（特别是GitLab，但不是GitHub）也会在进行此操作时从diff中排除这些文件（没有超过10k行更改！）。

我不在项目中提交此文件。有什么意义？

它是生成的这是gitlab-ci.yml构建的gitlab中SHA1代码完整性错误的原因

虽然我确实从未在package.json中使用^作为libs，因为我有过不好的体验。

是的，package-lock.json打算签入源代码管理。如果您使用的是npm5+，您可能会在命令行上看到以下通知：创建了一个名为package-lock.json的锁定文件。您应该提交该文件。根据npm帮助package-lock.json：

package-lock.json是为npm所在的任何操作自动生成的修改node_modules树或package.json生成的确切树，以便后续安装能够生成相同的树，而不考虑中间的依赖关系更新。此文件旨在提交到源存储库中各种用途：描述依赖关系树的单一表示，以确保队友、部署和持续集成能够安装完全相同的依赖关系。为用户提供一种工具，让他们“时间旅行”到node_module的先前状态，而不必提交目录本身。通过可读的源代码控制差异，帮助提高树更改的可见性。并通过允许npm跳过先前安装的包的重复元数据解析来优化安装过程。package-lock.json的一个关键细节是它无法发布如果在顶层包以外的任何位置找到，将被忽略。它共享npm-shrinkwrap.json格式，基本上是相同的文件，但是允许发布。除非部署CLI工具或否则使用发布过程来生产生产包。如果package-lock.json和npm-shrinkwrap.json都存在于包package-lock.json将被完全忽略。

是的，提交package-lock.json是一种标准做法。

提交package-lock.json的主要原因是项目中的每个人都使用相同的包版本。

赞成的意见：

如果您遵循严格的版本控制，并且不允许自动更新到主要版本，以避免在第三方包中发生向后不兼容的更改，那么提交包锁定会有很大帮助。如果您更新了一个特定的包，它会在package-lock.json中更新，并且使用存储库的每个人在接受您的更改时都会更新到该特定版本。

欺骗：

这会让你的拉取请求看起来很难看：）

npm安装无法确保项目中的每个人都使用相同的软件包版本。npm ci将对此有所帮助。

将package-lock.json提交到源代码版本控制意味着项目将使用特定版本的依赖项，该依赖项可能与package.json中定义的依赖项相匹配，也可能与之不匹配。虽然依赖项具有特定版本，但如您所见，没有任何Caret（^）和Tilde（~），这意味着依赖项不会更新到最新版本。npm install将获取当前版本Angular所需的相同版本。

注意：package-lock.json强烈建议在CI期间将任何Caret（^）和Tilde（~）添加到要更新的依赖项时提交它。

是的，它打算被签入。我想建议它获得自己独特的提交。我们发现它给我们的差异增加了很多噪音。