将 npm 的“package-lock.json”置于版本控制之下有什么意义？

Question

将 npm 的 package-lock.json 置于版本控制之下有什么意义？根据我的经验，控制此文件源所带来的麻烦和困惑比效率提升要多。

每次添加/删除/修改任何节点模块的开发人员需要解决分支之间的冲突时，将package-lock.json 置于源代码控制之下都会导致头疼。特别是在 package-lock.json 可能长达数万行的复杂/大型应用程序上工作。即使只是删除 node_modules 并运行一个新的npm install 也会在包锁中产生巨大的变化。

关于包锁还有其他几个 SO 问题：

• Do I commit the package-lock.json file created by npm
• Npm - package-lock.json role
• Why does npm install rewrite package-lock.json?

还有一个 GitHub 问题，其中包含大量关于包锁定的对话：

• package-lock.json file not updated after package.json file is changed

这让我认为仍然存在需要消除的广泛不确定性。

根据文档

package-lock.json 会为 npm 修改 node_modules 树或 package.json 的任何操作自动生成。

那么为什么要将自动生成的文件置于源代码管理之下？

上述 GitHub 问题详细说明了一些人如何响应与 package-lock.json 的混淆，将他们的 npm install 脚本更改为 rm -f package-lock.json && npm install，这也感觉不正确。

似乎package-lock.json 正在努力成为节点模块依赖项的确切版本的真相来源，但这不正是 package.json 所做的吗？解决此文件中的合并冲突的痛苦何时开始得到回报？

Answer 1

IMO package-lock.json（或yarn-lock.json）应始终致力于源代码控制。除了合并/变基冲突（yarn 顺便说一句，您可以通过yarn install mid-rebase 自动解决问题），这是您拥有该提交的代码将在一个全新结帐并安装。

Answer 2

创建一个 .gitattributes 条目：

# common settings that generally should always be used with your language specific settings

# Auto detect text files and perform LF normalization
* text=auto

#
# The above will handle all files NOT found below
#

#*.svg text
*.lock binary

然后，当您合并时，您只需选择版本与代码合并。以为这样你可能会遇到包冲突。

我们通过在构建过程中检查版本来缓解这种情况。

Answer 3

根据我的经验，将package-lock.json 置于版本控制之下是没有意义的。它使管理大型合并/变基成为一场噩梦。但是，在某些情况下，package-lock 可能非常有用。

最近（2017/10/10）moment.js 引入了breaking changes in a minor version update。意思是如果一个人要在没有 package-lock.json 的情况下发货，并且在他们的 package.json 中有这样的东西：

"moment": "^2.12.0"

2.19.0 版中引入的一些重大更改会悄悄地渗透到您的代码中，几乎没有任何痕迹。

这就是为什么在切割一个分支以作为候选版本之后，以下几点至关重要：

• 从 .gitignore 中移除 package-lock.json
• 运行npm install 生成一个package-lock.json
• 使用此包锁进行测试、质量检查、部署

这可确保您的 npm 模块版本将保持锁定在已测试的相同版本上。