31

将 npmpackage-lock.json置于版本控制之下有什么意义？根据我的经验，控制此文件源会导致比提高效率更多的麻烦和混乱。

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

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

还有一个关于包锁的大量对话的 GitHub 问题：

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

根据文档

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 所做的吗？解决此文件中的合并冲突的痛苦何时开始得到回报？

4

3 回答 3

11

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

最近 (2017/10/10) moment.js在次要版本更新中引入了重大更改。这意味着如果一个人要在没有 package-lock.json 的情况下发货，并且在他们的 package.json 中有这样的东西：

"moment": "^2.12.0"

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

这就是为什么在切割一个分支作为候选发布后，关键是：

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

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

于 2017-10-16T16:00:36.840 回答
4

创建一个 .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

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

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

于 2018-01-25T23:37:39.247 回答
3

IMO package-lock.json（或yarn-lock.json）应始终致力于源代码控制。除了合并/变基冲突（yarn顺便说一句，这在很大程度上减轻了 - 您可以yarn install在中间变基以自动解决问题），这是您拥有该提交的代码将在全新签出和安装后正确构建和运行的最佳保证。

于 2018-11-25T11:52:41.330 回答