我们在所有确定性pkg安装中都使用yarn，但是并不能阻止用户使用npm-我猜测同时拥有这两个文件会引起问题。应该添加一个到您的.gitignore目录吗？

通常总是提交依赖项锁定文件

正如覆盖在其他地方，依赖锁文件，这是由很多的包管理系统的支持（如： 作曲家和打捆），应致力于在结束链项目的代码库-让每个人尝试运行该项目正在做因此具有完全经过测试的依赖关系集。

尚不清楚是否应始终将锁定文件提交到旨在包含在其他项目中的软件包中（需要更宽松的依赖关系）。但是，Yarn和NPM（由@Cyrille涵盖）都可以智能地忽略它们，yarn.lock并package-lock.json在必要时分别忽略它们，从而使始终提交这些锁定文件很安全。

因此，您应始终至少提交一种yarn.lock或package-lock.json取决于您使用的软件包管理器。

您是否应该同时提交yarn.lock和package-lock.json？

目前我们有两个不同的包管理系统，安装都同样依赖集从package.json，但生成并从两个不同的lockfiles读取。NPM 5生成package-lock.json，而Yarn生成yarn.lock。

如果提交，package-lock.json则表示正在支持使用NPM 5安装依赖项的人员。如果提交yarn.lock，则表示正在支持使用Yarn安装依赖性的人。

是选择提交yarn.lock还是选择提交还是package-lock.json取决于两者，取决于在项目上进行开发的人员是仅使用Yarn还是NPM 5或两者都使用。如果您的项目是开源的，那么对社区最友好的事情可能就是同时提交这两者，并有一个自动化的流程来确保yarn.lock并package-lock.json始终保持同步。

更新： Yarn现在引入了一个import命令，该命令将从yarn.lock文件生成package-lock.json文件。这对于使两个文件保持同步可能很有用。（感谢@weakish）

在以下的Yarn项目中详细讨论了此问题：

• “想法：从npm 5支持package-lock.json”
• “竞争的锁文件会导致不良的UX”

两者都已关闭。

您应该提交1个依赖关系树锁定文件，但不要同时提交两个。这还需要对yarn或npm（不是两者）进行标准化，以构建+开发项目。

以下是有关纱线的文章，如果您对纱线进行了标准化，为什么应该执行yarn.lock。

如果您同时提交yarn.lock文件和package-lock.json文件，则有很多方法可以使这两个文件提供不同的依赖关系树（即使yarn和npm的树分辨率算法相同），确保它们提供的依赖关系也不是一件容易的事。相同的答案。由于它是不平凡的，因此不太可能在两个文件中都维护相同的依赖关系树，并且您不希望根据构建是使用yarn还是npm完成而获得不同的行为。

如果并且当yarn从使用切换yarn.lock为package-lock.json（在此处发出），那么选择要提交的锁定文件就变得容易了，并且我们不再需要担心yarn和npm会导致版本不同。根据此博客文章，这是我们不应该期待的更改（该博客文章还描述了yarn.lock和之间的区别package-lock.json。

我在想同样的问题。这是我的想法，希望对您有所帮助：

在NPM包lock.json文档说以下：

对于npm修改node_modules树或package.json的任何操作，都会自动生成package-lock.json。它描述了生成的确切树，因此无论中间依赖项更新如何，后续安装都可以生成相同的树。

这很棒，因为它可以防止“在我的机器上工作”的影响。

如果没有此文件，npm install --save Anpm将添加"A": "^1.2.3"到您的中package.json。当别人运行npm install你的项目，有可能是版本1.2.4的A已被释放。由于它是满足您指定的semver范围的最新可用版本package.json，因此它将安装该版本。但是，如果此版本中引入了新的错误怎么办？此人将遇到一个无法复制的问题，因为您具有以前的版本，没有任何错误。

通过修复node_modules目录的状态，package-lock.json文件可以防止此问题，因为每个人的每个软件包的版本都相同。

但是，如果您正在编写和发布npm模块呢？该文档说：

关于package-lock.json的一个关键细节是它无法发布，并且如果在顶级软件包之外的任何地方都将被忽略。

因此，即使您提交它，当用户安装模块时，他/她也不会获取package-lock.json文件，而只会获取package.json文件。因此，npm将安装满足您所有依赖关系的semver范围的最新版本。这意味着您始终希望使用这些依赖关系的版本来测试模块，而不是在开始编写模块时安装的版本。因此，在那种情况下，package-lock.json显然是没有用的。而且，这可能很烦人。

这是我的经验法则：如果您正在处理应用程序，请提交锁定文件。如果要维护库，请将其添加到忽略列表中。无论哪种方式，您都应该在中使用准确的semver范围package.json。Yehuda Katz（已缓存）为何时提交Gemfile.lock（Ruby的锁定文件）以及何时不提交做出了很好的解释。至少阅读tl; dr部分。

没错！同时允许npm和yarn都会导致问题。看一下这篇文章。

目前，我们正在计划一些警告添加到谁使用两个用户 yarn，并npm在同一仓库安装软件包。

package-lock.json如果您决定使用纱线，我们强烈建议您删除该文件，以避免将来造成混乱和可能的一致性问题。

您可能不希望两者兼而有之npm，yarn同时又要作为包管理器。

这些文件由您的工具管理，因此-假设使用yarn将有效地更新package-lock.json-我想提交两个文件都可以正常工作。

我认为对您的用户来说最重要的是package-lock.json（例如，我不使用纱线），因此必须坚持这一点。

对于yarn.lock，取决于您是一个人还是团队工作。如果是独奏，那么我认为没有必要提交它。如果您（计划）在一个团队中工作，那么您可能应该提交它，至少直到yarn 支持它为止。

我想纱线团队最终将停止使用yarn.lock，package-json.lock而是改为使用，这时它将变得更简单😛

不，同时使用两个锁定文件通常会导致依赖性树不一致，尤其是在团队协作时。忽略一个或另一个锁是一个简单的解决方案。只要确保您的团队了解并同意此更改即可。