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

Question

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

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

还有其他几个关于包锁的问题:

• 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 is automatically generated for any operations where npm modifies either the node_modules tree, or package.json.

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

上述 GitHub 问题详细介绍了一些人如何因对 package-lock.json 的混淆而将其 npm install 脚本更改为 rm -f package-lock.json && npm安装，这也感觉不正确。

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

Answer 1

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

最近(2017/10/10)引入了 moment.js breaking changes in a minor version update 。意思是如果不带 package-lock.json，并且在 package.json 中包含类似的内容:

“时刻”:“^2.12.0”

版本 2.19.0 中引入的一些重大更改会悄无声息地渗透到您的代码中，几乎不留痕迹。

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

• 从 .gitignore 中删除 package-lock.json
• 运行npm install生成package-lock.json
• 使用此包锁进行测试、质量保证和部署

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