Yarn: 我是否需要将 yarn.lock 放在 .gitignore 中？

您应该将 yarn.lock 添加到您的 git 中，不要忽略它。

请参阅https://yarnpkg.com/en/docs/migrating-from-npm

当您运行yarn或yarn add <package> ，Yarn 将在您的包的根目录中生成一个yarn.lock文件。 您无需阅读或理解此文件 - 只需将其签入源代码管理即可。 当其他人开始使用 Yarn 而不是npm ， yarn.lock文件将确保他们获得与您完全相同的依赖项。

需要明确的是 - 这也适用于库，而不仅仅是应用程序，因为与npm-shrinkwrap.json相反，只有顶级项目的yarn.lock会被使用，对吧？ 所以与yarn.lock文件的依赖关系不会产生不必要的重复。 如果您有复杂的开发依赖项并且您希望库的每个贡献者都具有相同的构建和测试配置，那么它对库很有用。

这样对吗？

@goenning
也许将 yarn.lock 文件放在您的存储库中并不总是最好的主意。
例如，我正在使用 sinopia。 因此我有一个自定义的 npm 注册表。 我将此注册表主要用于我拥有私有模块的其他项目。
但是当我将一个公共项目推送到一个只有公共依赖的 git 存储库时，yarn.lock 有错误的依赖链接，我的 CI 系统将无法构建该项目。
依赖项指向我的本地存储库。
如果其他开发人员克隆我的存储库，这也可能发生在他们身上。
除了将 yarn.lock 文件放入 gitignore 之外，还有什么办法可以解决这个问题？

另外，如果你有预先认证的 npm 注册表，例如 myget 代理 npm， yarn.lock将有预先认证的包链接，这是一个重大的安全漏洞 🎉
这应该用大字体记录在某个地方。

@Pfeifenjoy如果您使用 git submodule 而不是 npm 链接到私有包怎么办？
使用 git，您可以使用部署密钥（通过 ssh）访问存储库

@beenotung我不喜欢使用 git 作为依赖项管理器，因为它非常慢，不能按照我希望解决的方式解决依赖项，在我看来，最好将每个依赖项都放在一个管理器中。

此外，我引用的依赖项（不仅是我自己的项目）都将获得不同的地址，因为它们保存在我本地的 sinopia 帐户中。 在 git 中引用我的项目所依赖的所有节点模块会非常乏味。
此外，删除 yarn.lock 文件更容易。

@Pfeifenjoy你想要纱线做什么可能有冲突吗？ 如果您想提供一种方法来确保其他安装具有您的依赖项，请包含它 - 它按预期执行。 如果您要获取私有存储库和源代码，则应该非常谨慎地考虑如何共享您的代码，就像您特别会忽略存储库中的任何键或盐一样（如果您想查看在项目自述文件中发出警告，我会提出一个功能/拉取请求）。

可能 yarn 在运行时应该发出警告，提醒用户访问经过身份验证的源已包含在锁定文件中，但同样，这将是一个功能请求。

@thisolivier听起来很合理

只是一个备忘录。
由于https://github.com/yarnpkg/yarn/issues/3330 ，如果您居住在中国或其他禁区，并使用其他注册表（eq taobao）构建模块，则应将yarn.lock到.gitignore 并将package-lock = false写入 .npmrc。

这里为什么我不提交我的yarn.lock ：某些模块具有本机依赖项并且仅适用于某些平台（与生成yarn.lock的平台完全相似的平台）。
为了让我的用户满意并且没有错误的安装，我删除了纱线 - 除非纱线提供一个带有清晰文档的解决方案如何解决这个问题，否则我会同意。
（总是从开发者那里听到真实的故事）

它也让你的提交变得非常丑陋。

我不同意这里最受好评的评论：

• 如果项目使用 npm，将package-lock.json提交到 repo 和 gitignore yarn.lock
• 如果项目使用纱线，将yarn.lock提交到 repo 和 gitignore package-lock.json

也就是说，你应该_不_总是将 yarn.lock 提交到 repo ，并回答 OP 的问题，是的，你可能想将它添加到.gitignore 。

当其他人开始使用 Yarn 而不是 npm 时，yarn.lock 文件将确保他们获得与您完全相同的依赖项

首先，不，它不会 - 仅当您只使用公共 npm 注册表时。 更糟糕的是，如果您没有在 yarn 中授权到您的私有组织（即使您仍然在 npm 中），并且公共注册表中存在同名的包，它只会在没有提示的情况下安装错误的包。 令人困惑的是，为什么您的 yarn 安装时没有错误，但该应用程序在使用 yarn 时不起作用，而在使用 npm 时却起作用。

其次，许多代码库_不_使用纱线。 这不是“他们何时切换到纱线”的问题。 几乎我所有的节点服务和基本 Web 服务器都使用 npm，没有计划迁移到 yarn。 我确实喜欢用 React 编写 yarn，仅此而已。

正如@Pfeifenjoy上面提到的：

我有一个自定义的 npm 注册表。 我将此注册表主要用于我拥有私有模块的其他项目

但是当我将一个公共项目推送到一个只有公共依赖的 git 存储库时，yarn.lock 有错误的依赖链接，我的 CI 系统将无法构建该项目。

^ 另一件事，即使您在本地解决它，您也必须将解决方案合并到 yaml 或 CI 的任何配置中以及您启动应用程序的任何其他地方 - 某种逻辑可以判断何时使用哪个注册表和哪个命令 -听起来很烦人而且没有必要

另一件事 - 如果你鼓励每个人总是向 repo 提交yarn.lock并且永远不会忽略它，开发人员将开始在已经严重依赖 npm 的 repo 中使用 yarn。 即使在它工作正常的情况下，2 个锁定文件中也会存在冗余，这将为依赖地狱打开一扇门。 而且您知道某些开发人员会在某个时候提交 ~25k 行yarn.lock来弄乱您的贡献图 :joy: