删除 `package-lock.json` 以快速解决冲突答案

【问题标题】：Deleting `package-lock.json` to Resolve Conflicts quickly删除 `package-lock.json` 以快速解决冲突
【发布时间】：2019-06-05 01:09:36
【问题描述】：

在团队设置中，我通常在package-lock.json 中遇到合并冲突，而我的快速解决方法一直是删除文件并使用npm install 重新生成它。我没有认真考虑过这个修复的含义，因为它之前没有引起任何可察觉的问题。

删除文件并让npm 以这种方式重新创建它而不是手动解决冲突是否有问题？

【问题讨论】：

参考这个答案 - stackoverflow.com/a/44297998/2251411
@john-mutuma 由于 npm 的解决方案比接受的答案要简单得多，也许您应该考虑接受下面的（我的）解决方案 :-) 为什么要浪费时间在可以为您解决很多问题的事情上更轻松？ :-)

【解决方案1】：

是的，它可以并且将以非常糟糕的方式影响所有项目。

如果您的团队没有在每个 git pull 之后运行 npm install，那么您都在使用不同的依赖项版本。所以它以“但它对我有用！！”结尾和“我不明白为什么我的代码不适合你”
即使所有团队都运行npm install，但这并不意味着一切正常。在某些时候，您可能会发现您的项目表现不同。在你多年来没有改变的部分。在（可能非常痛苦）调试之后，您会发现这是因为 3 级依赖项已针对下一个主要版本进行了更新，这导致了一些重大更改。

结论：永远不要删除package-lock.json。

是的，对于第一级依赖项，如果我们指定它们没有范围（如"react": "16.12.0"），我们每次运行npm install 时都会得到相同的版本。但是我们不能对 2+ 级深度的依赖项（我们的依赖项所依赖的依赖项）说同样的话，所以package-lock.json 对稳定性非常重要。

在你的情况下，你最好做下一个方法：

看起来很简单。与 yarn 一样——它自己修复了 lockfile 冲突。这里唯一的要求是提前解决package.json 中的所有冲突（如果有）。

根据docs，npm 将为您修复package-lock.json 中的合并冲突。

[2021 年更新] 重要！如果你已经使用了一些库，并且它的维护者的 npm/GitHub 帐户被黑了。并且发布了包含恶意代码的新版本。你有package-lock.json 完好无损。你会好起来的。如果你放弃它，你就有麻烦了。

【讨论】：

使用方法 2，我注意到它很容易导致我最终使用方法 1 的问题，所以我建议首先使用方法 1。
@toni_lehtimaki 为什么基本上是一样的？如果您选择首先基于当前的package-lock.json 进行变基或在合并时接受“他们的”package-lock.json，它们实际上是相同的。还是我在这里遗漏了什么？
@JRichardsz，您仍然没有显式控制传递（间接，2nd+ 级）依赖项
这个答案的最后一行是关键。在拉出并看到合并冲突仅在 package-lock.json 文件中之后，您可以执行 npm install 并为您解决它们（然后您只需要暂存/提交/等）。 TIL :) 感谢您的提示！
等等，无需解决yarn.lock 内部的冲突。仅在 package.json 内部

【解决方案2】：

是的，它可能会产生不好的副作用，可能不是很常见，但例如您可以在 package.json 中拥有 "moduleX": "^1.0.0"，而您曾经在 package-lock.json 中拥有 "moduleX": "1.0.0"。

通过删除 package-lock.json 并运行 npm install，您可能会在不知情的情况下更新到 moduleX 的 1.0.999 版本，并且可能他们已经创建了一个错误或进行了向后的重大更改（不遵循语义版本控制）。

反正已经有标准解决方案了。

【讨论】：

【解决方案3】：

我知道这是一个老问题，但对于未来的寻求者，您还可以使用 npm-merge-driver 尝试自动解决 npm 相关文件的合并问题。

只需全局安装npx npm-merge-driver install --global。你可以在这里阅读更多关于它的信息npm-merge-driver

编辑：只是想警告对使用上述软件包感兴趣的人，有时它的行为可能会出现异常且难以删除。所以虽然它是一个有用的工具，但它仍然需要一些工作。

编辑：此存储库现在已存档且只读。

【讨论】：