Yarn: 竞争的锁文件会导致不良的UX

将配置添加到package.json以指示

对于engine字段，这可能是一个很好的用例🤔

往返package-lock.json → yarn.lock → package-lock.json是有损的，但这可能并不重要。 yarn.lock → package-lock.json → yarn.lock不应该是有损的，AFAIK。

从npm角度来看，我赞成以下选项：如果yarn看到package-lock.json而不是yarn.lock ，它将导入并删除package-lock.json 。 同样，如果npm看到yarn.lock而没有package-lock.json则应该执行相同的操作，导入并删除`yarn.lock。

这将允许这两种工具的用户无缝地来回切换，而不会使用户的项目处于混乱的状态（文件似乎来自两者）。

我对此有点担心，因为这意味着package-lock.json或yarn.lock都无法将元数据添加到文件中（Yarn当前不能，但是为什么不能），因此删除了一些在此过程中自由使用我们的格式。

这个问题也提出了一般在另一个线程中讨论的Yarn和npm之间的互操作性问题-我觉得尝试太互操作可能值得我们两个人，因为用户将期望所有东西都将以完全相同的方式工作在这两个项目上，我认为这是一个危险的假设（一个明显的例子是，如果有人在由工作区驱动的项目上运行npm，则工作区将无声地中断）。

@ yarnpkg / core，有什么想法吗？

我喜欢@iarna的想法，可以使两种工具都从一个锁定文件迁移到
另一个自动安装。
在迁移后删除导入的锁定文件很有意义，以避免
两个包经理在一个项目中竞争。

两种工具都可以打印警告，并可能需要用户提示才能继续。

我也同意Mael的观点，即实现100％的兼容性将锁定
我们从探索新功能开始，我认为我们应该将其视为一次性
迁移路径，这可能是我们install.js中的一个很小的功能
侧。

在2018年4月11日，星期三，9：49 PMMaëlNison [email protected]写道：

我对此有点担心，因为这意味着
package-lock.json或yarn.lock将能够向文件添加元数据
（纱线目前不提供，但为什么不提供），消除了我们格式的一些自由
正在进行中。

这个问题也提出了纱线与纱线之间的互操作性问题。
一般而言，npm，最初在另一个线程中讨论过-我想尝试
太互操作可能值得我们俩，因为用户会
期望两者都能以完全相同的方式工作
我认为这是一个危险的假设（一个明显的例子是
如果有人在某个计算机上运行npm，则工作区将默默中断
工作区驱动的项目）。

@ yarnpkg / core https://github.com/orgs/yarnpkg/teams/core ，有什么想法吗？

-
您收到此消息是因为您所在的团队是上述人员。
直接回复此电子邮件，在GitHub上查看
https://github.com/yarnpkg/yarn/issues/5654#issuecomment-380677110或静音
线程
https://github.com/notifications/unsubscribe-auth/ACBdWI9jnLJeFqH8v2T-AB74sQO1PMIjks5tntzrgaJpZM4TQ5-B
。

Pinging @ imsnif，因为他

感谢您的ping！

所以，是的，我实际上正处于为此工作之中。 我正计划编写一个RFC纱线，并在下周对所有利益相关者进行ping操作。

简而言之：我已经完成了转换yarn.lock <==> package-lock.json的工作。 在此过程中有一些损失，但是很少是合乎逻辑的。 在我看来，如果我们正在谈论上面提到的“一次性转换”方案，这是完全可以接受的。 如果我们想进一步讨论，我可以详细介绍。

我目前有一些执行此操作的基本代码： https :
它不是100％，而是依赖于要转换的项目的现有和当前node_modules文件夹。 我正处于重写的最后阶段（在分支2.0.0 ），它将从注册表中获得程序包状态（使用令人敬畏的pacote lib）。

一旦完成，我想做的就是开始谈论我们如何（以及是否？）完全在yarn和npm实现这一点。

很想听听大家对此的想法。

在我看来，如果我们谈论上面提到的“一次转换”方案，这是完全可以接受的

我认为这不会那么普遍。 我可能是错的，但我觉得更常见的用例是使用Yarn的项目，并且一名开发人员使用README复制/粘贴命令以添加依赖项，使用npm而不是yarn在此过程中。

在这种情况下，我仍然不相信通过尝试做正确的事来丢失数据并以无提示的方式更改程序包布局是一件好事-他们可能甚至不会注意到它，直到事情破裂为止（我们可能会有一个确认提示，但是我希望复制/粘贴这些命令的人也盲目地确认安装提示）。 更糟糕的是，它可以在自己的机器上运行，但是一旦他们切换回Yarn，就可以破坏他们同事的机器。

@arcanis-我认为所有场景和边缘案例都非常值得讨论。 在您提到的场景中，我非常同意，但是我认为在其他场景中，应该对一个锁文件有明显的偏见。

我认为此功能主要用于CI环境中，在该环境中我认为它可以发光（如OP所述）。 不过，至少在某种程度上，我认为这两个工具都应该知道另一个工具的锁定文件？ 留下他们决定何时进行转换的细节。 你怎么看？

我认为此功能主要用于CI环境中，在该环境中我认为它可以发光（如OP所述）。

你有例子吗？ CI系统应该以一种确定性的方式运行，在PR-time imo上，意外提交转换后的锁定文件应该变得更糟，CI为此为时已晚。

不过，至少在某种程度上，我认为这两个工具都应该知道另一个工具的锁定文件？

也许。 使用engine版本强制特定的包管理器对我来说看起来更干净，两个项目都只需要保留一个排他引擎列表（例如，“ npm”上不能满足“ yarn”，反之亦然）。

在我看来，即时转换锁文件也不是很可扩展。 例如，到目前为止，我们只是在谈论package-lock.json文件，但是我认为pnpm有自己的锁定文件，称为shrinkwrap.yaml 。 很好，我们可以找到一种方法来处理这两种方法以及可能会遇到的任何其他格式。

我认为此功能主要用于CI环境中，在该环境中我认为它可以发光（如OP所述）。

还要注意，如果我理解正确，npm当前正在使用特定于CI的非常轻便的软件包管理器，对于需要大量业务逻辑的事情（例如锁文件转换器），它可能无法很好地工作。

关于CI：
我最初的想法是：在使用相反的工具添加新软件包时发出警告，在进行全新安装时进行转换（或更保守地说：默认情况下在全新安装上失败，并通过import命令或config标志详细地允许转换安装）。

当我以前在npm / yarn混合环境中工作时，我们实际上将使用git历史记录手动进行此操作。 这是一个艰苦的过程，我敢肯定我们并不孤单。

至于可扩展性：
我也想解释这个。
执行转换时，将创建一个中间逻辑和物理包树（如果锁文件包含一个）。 当转换为所需的锁定文件时，将使用这些树（或以合理的默认值创建，以防我们从yarn而没有物理树）。
这样，我们就可以轻松地在其他锁定文件类型之间进行转换（我们要做的就是为每种类型的逻辑树/物理树提供转换）。

目前，这显然比该工具的功能领先一点，但是我认为实现此功能不是一个大问题。

（关于npm的新ci工具-我明白你的意思，但是我认为这比当前的讨论要早一些吗？）

或更保守地说：默认情况下在全新安装上失败，并且详细地允许通过导入命令进行转换

是的，我完全想将这种转换逻辑添加到yarn import命令中，这似乎是一个有用的功能，如果/当我们要实现Yarn插件时，可以将其提取到一个单独的包中：)我的评论是关注我们应该采用的默认行为。

从npm@6 ，您应该能够无损转换package-lock.json -> yarn.lock ，而不必先运行安装。 它应该包含您需要的所有数据，标识符等（npm @ 6的pkglock在requires字段中具有版本范围，该范围与yarn.lock使用的匹配？）

哦，而且在此之前，还需要发送https://github.com/yarnpkg/yarn/pull/5042 ，因为npm在很多pkglock中都没有sha1案件。

@arcanis-太棒了！ PR也会：

1. 安装并找到package-lock.json文件时的警告
2. 添加和查找package-lock.json文件时的警告
3. 通过import命令添加从package-lock.json转换的能力（并在此后删除文件）
   可以接受吗？ （这样我们就可以使用某些内容来开始具体对话）

@zkat-大约npm@6太好了！ 如果要由我决定，我会选择使用它并回退清单文件以支持所有锁文件版本。 请问您是否愿意为npm实施类似（或可能有所不同）的行为？

还要注意，如果我理解正确，npm当前正在使用特定于CI的非常轻便的软件包管理器，对于需要大量业务逻辑的事情（例如锁文件转换器），它可能无法很好地工作。

如果“当前正在处理”是指“已经发货”，则可以。 =）

如您所建议，当前加载yarn.locks已超出其范围（因为它不知道如何布局包树），但是如果我们最终都拥有一个可以进行布局的库，那么我不反对让它支持加载纱锁。 （理想情况下，这将是它和Yarn之间共享的库。）显然，对于这种情况，它不应删除现有的锁定文件。 就包元数据而言，它是纯只读的。

安装和找到package-lock.json文件时的警告

我担心仅在存在不支持的一种锁定文件时发出警告不会解决Heroku遇到的@jmorrell引发的问题吗？

我担心仅在存在不支持的一种锁定文件时发出警告不会解决Heroku遇到的@jmorrell引发的问题吗？

警告可能会有所改善，但良好的消息传递错误将是用户imo的理想选择。 我只能为自己说话，但是我有几个项目，有些使用yarn，有些使用npm，而且我经常发现自己在该项目中输入了错误的项目。 一个快速的错误意味着我可以立即使用从一开始就应该拥有的产品。

如果是警告，则它应该很大且很明显。 IME用户受过良好的训练，希望他们可以忽略软件包管理器的输出，只要它能正常工作。

我接触了一些对初学者有更多经验的人，希望他们对刚刚起步的人有什么样的体验。

CI系统应该以一种确定性的方式运行，在PR-time imo上，意外提交转换后的锁定文件应该变得更糟，CI为此为时已晚。

我同意。 理想情况是，在到达构建/ CI服务时，应用程序不会处于不确定状态。 在这种情况下，我不会感到不满意的唯一方法是，如果有一种可接受的方式让用户在package.json指出他们的偏好，但是这种解决方案也给用户带来了更多负担。

我担心仅在存在不支持的一种锁定文件时发出警告不会解决Heroku遇到的@jmorrell引发的问题吗？

通过在实际使用Heroku之前警告用户他们正在做他们可能不想做的事情，这将对他们有帮助。 我不确定会实际改变多少，但是我们可以在几周后检查一下，看看是否需要进一步处理。 而且由于所需的更改相对较小，因此这可能是一个不错的第一次迭代。

对于那些提出警告诚信问题：有没有的情况下运行yarn install或yarn add而package-lock.json存在不会是一个错误？ npm install和yarn.lock同上

我想到了从npm迁移到Yarn或从Yarn迁移到npm。 当想要尝试其他软件包管理器时，我宁愿避免增加摩擦。

要记住的一件事是警告和错误不是互斥的，或者至少不是与engine字段互斥的。 没有固定包管理器的项目可能会打印警告，而带有固定包管理器的项目可能会出错。 这样，用户可以自由地从一个程序包管理器切换到另一个程序包管理器，直到他们做出选择并相应地配置package.json为止。

engine字段的另一个优点是，它可以让您确定必须使用哪个版本的软件包管理器。 我猜它可以在某处配置，但是使用此系统，它将成为常规工作流程的一部分。

engine字段的另一个优点是，它可以让您确定必须使用哪个版本的软件包管理器。 我猜它可以在某处配置，但是使用此系统，它将成为常规工作流程的一部分。

是否有engine字段，或者您是指engines ？ 我找不到任何引用engine文档。 抱歉，如果我错过了什么。

我们支持在engines字段中指定版本： https ://devcenter.heroku.com/articles/nodejs-support#specifying -an-npm-version

例如：

  "engines": {
    "npm": "5.6.x"
  }

使用此方法来确定要使用的程序包管理器时，我有一些担忧：

• 今天的样子：数量不多的用户同时定义了npm和yarn或npm版本，但是他们有yarn.lock 。 npm和yarn将来版本可以强制执行此操作，但是不经常升级的用户将长时间使用当前版本。

• 大多数用户从不触摸此配置。 他们分叉了一个旧的样板，该样板指定了节点0.10即使他们使用从机器上从nodejs.org下载的任何内容。 这会在Heroku上引起大量问题。

• 团队通常不协调他们已安装的版本。 他们安装的Node或npm或yarn的版本通常是项目启动时的最新版本，或者上一次中断并迫使它们重新安装的版本。 并不是说这是理想的，但我的理解是，大多数npm / yarn用户都是初学者，这为入门增加了新的障碍。

例如：“我克隆了一个示例hello-world项目，从https://nodejs.org下载了Node，但是它不起作用”

话虽如此，如果工具强制执行严格的版本并将其记录在engines ，我会非常喜欢。 这样可以避免我每天看到的许多错误，但这感觉是一个很大得多的变化。

话虽这么说，如果这些工具强制执行严格的版本并将其记录在引擎中，我会非常喜欢。 这样可以避免我每天看到的许多错误，但这感觉是一个很大得多的变化。

AFAIK Yarn严格执行此字段，除非您传递一个标志来禁用它。

团队通常不协调他们已安装的版本。 他们安装的Node或npm或yarn的版本通常是项目启动时的最新版本，或者上一次中断并迫使它们重新安装的版本。

这非常危险，特别是在使用Yarn时，因为它只能保证在相同主要版本的Yarn中保持一致。

并不是说这是理想的，但我的理解是，大多数npm / yarn用户都是初学者，这为入门增加了新的障碍。

Yarn（如果他们喜欢这个想法的话，也是npm）如何在engines字段中添加"yarn": "^<current_version>"条目以帮助引入一些安全性而又不会产生太大的摩擦？ 当运行yarn init ， yarn import或从头开始创建锁文件时，我们可以自动添加它。

我对Yarn不太了解，但是我认为最好的解决方案是将package-lock.json解析器添加到Yarn中，并且不要创建yarn.lock如果存在）。

我认为最终目标应该是在Yarn和npm之间共享一种锁定文件格式。

@thatlittlegit然后，您将很高兴了解https://github.com/yarnpkg/yarn/pull/5745 。 （npm会反向执行相同的操作，因此我们最终将处在无关紧要的位置，无论您使用哪种类型的锁定文件或选择哪种工具。）

编辑补充：我认为，单一的锁定文件格式不可能实现，因为在锁定文件格式之间存在不同的权衡取舍，并且对于哪种最佳文件格式缺乏共识。 我认为使这两个工具能够相互理解彼此的锁定文件就足够了。

除此之外，拥有多个可以做出不同折衷选择的，积极使用的工具还有很多优点，因为这意味着与单个通用解决方案相比，可以更好地满足用户用例。

@BYK有关引擎字段行为的一些历史记录可能对您有帮助：

在NPM @ 1和NPM @ 2 ，我们有一个package.json称为engineStrict除了engine领域。 如果engineStrict为true，则将engine字段用作_resolution约束_，并且在将semver范围应用于版本列表之前，将过滤出引擎不兼容的版本。 即使平台上不支持[email protected] ，即使发布了[email protected] ，这也可以让您执行npm install foo并获得[email protected] 。 这似乎是可取的，但实际上却非常令人困惑，尤其是因为网站上的文档仅适用于最新版本。

如果engineStrict为假，则不考虑引擎字段就进行了解析，如果结果不兼容，则会发出警告。

还有一个engine-strict配置选项，该选项与package.json属性相同，但将其应用于所有软件包。

从npm @ 3开始，我们放弃了对engineStrict package.json属性的支持，并更改了engine-strict config选项的行为。 现在，config选项会将您收到的警告变为错误，但不会影响分辨率。

engine字段不仅适用于顶层项目，而且可传递地执行。 引入yarn引擎标志将意味着依赖项只能与yarn一起安装，我认为情况并非如此。

由于在下一个yarn版本中，我们应该具有将package-lock.json导入到yarn.lock -我想回头讨论警告/错误问题。

我的观察方式：我不认为单个软件包同时拥有package-lock.json和yarn.lock文件是有充分的理由的。 我见过的大多数项目都知道这是需要解决的问题，而不是期望的情况（但我当然愿意予以纠正）。
从@iarna的上述解释可以理解， engine字段不是明确指定程序包正在使用哪个程序包管理器的好方法。
因此，IMO，这种情况应该产生冗长的错误，从而导致用户删除一个文件或对其进行转换。

但是，我认为产生这样的错误将是一个明显的突破性变化。 在纱线方面，我建议从警告开始（如上所述），然后慢慢弃用此行为，直到下一个主要版本将其更改为错误为止（也许添加一个配置标志，使两个文件都可以同时存在）。

大家怎么想 @jmorrell ， @BYK ， @arcanis ，@iarna吗？

在我看来，任何类型的项目都应指定应使用哪种程序包管理工具，这似乎很奇怪。 如果我错了，请纠正我，但我将Yarn视为直接替代的替代品，主要取决于最终用户的偏好。 Yarn是否试图将NPM完全替换为事实上的标准，还是试图共存？

@BrainBacon只有每个人都使用尊重相同锁定文件并使用相同语义的相同程序包管理器，才能获得锁定依赖项的好处。 如果一个项目有一个yarn.lock ，然后有人运行了一个npm install ，那么那个人仍然可能会遇到一组不同的依赖关系。 因此，不，不幸的是，它并不依赖于最终用户的偏好-最好，项目中的每个人都使用相同的包管理器。

这也意味着在一个项目中有两个锁文件是没有意义的。 它们不太可能解析为相同的依赖关系树，并且使贡献者不清楚使用哪个程序包管理器。

（当npm不生成锁文件时，插入替换部分尤其如此，因为那里没有丢失的信息。如果＃5745确实意味着Yarn现在可以基于package-lock.json生成锁文件，则仍然适用。

如果我错了，请纠正我，但我将Yarn视为直接替代的替代品，主要取决于最终用户的偏好。

就公开的API而言，Yarn不是直接替代。 yarn add <pkg>与npm install <pkg>是我们做事不同的明显例子。 我们的确倾向于具有相同的功能集，但最终它是两个不同的工具，有时我们对同一问题有不同的解决方案。

yarn.lock与package-lock.json就是这些区别之一，我相信Yarn和npm都不会对使用单个信息感兴趣，因为它们包含不同的信息。

在纱线方面，我建议从警告开始（如上所述）

我会很好的。 就像是：

WARN Your project seem to contain lock files (package-lock.json, shrinkwrap.json) generated
WARN by other tools than Yarn. It is advised not to mix package managers, in order to avoid
WARN resolution inconsistencies caused by desynchronized lock files.

有人想开公关吗？

我很乐意打开添加警告的PR :)

当package-lock.json存在+ yarn import时，所需的最终解决方案是否在这里是有用的错误？ 我的理解是@iarna提倡每个工具都应删除/转换相反的锁文件（如果该文件自动存在）。

两种解决方案都将对用户带来重大改进，但是我认为，最好是yarn和npm都选择相同的策略（但是，如果没有共识并且人们对此表示强烈反对，则并非绝对必要）。

@jmorrell-我的理解是，我们认为自动转换在这里不是一个好主意。

主要是因为很难知道两个锁文件之间的增量。
例如。 当我以开发人员的身份看到以上警告时，我可能想做的是弄清楚何时创建另一个锁文件，添加了哪些包而不添加到我的主锁文件中，然后添加它们。 也许使用import选项作为参考，但不一定。

我希望npm对此表示同意吗？

理想情况下，我希望警告中包括一些有关此情况的过时说明（不确定用词），并且将来的纱线版本会产生错误。 也许链接到有关此问题以及如何解决的一些详细文档。 @arcanis-您认为可行吗，还是宁愿warning行为？

如果两个工具在存在多个锁定文件时都发出error ，我认为开发人员将在这个问题仍然很小的情况下抓住这个问题，并能够迅速解决（借助导入作为参考） 。

@arcanis npm add <pkg>是完全有效的，并且可以执行Yarn的操作👼

至于pkglock vs yarnlock， package-lock.json初衷是创建一种格式，其中包含包管理器所需的所有数据。 实际上，从npm@6的pkglock可以透明地转换为yarn.lock，而无需执行安装程序，因为它描述了带有所有相关元数据的完整树。 我们是故意这样做的（例如requires字段），并且要求Yarn和pnpm团队提供反馈，以确保我们所做的一切足以使他们两个都用作可导入的锁定文件或作为替代选择。 不幸的是，yarn.lock是有损子集，因此反事实并非如此，但是无论如何我们都会添加一些东西来导入它。 npm甚至会服从Yarn计算的树形状（与Yarn不同，后者不会）。

实际上，从npm @ 6起的pkglock可以透明地转换为yarn.lock，而无需执行安装程序，因为它描述了包含所有相关元数据的完整树。

我认为这是不可能的（但是也许我误会了，随意指出任何误解）。 通过设计解析为单个版本的多个范围，不支持Yarn锁定文件。 如果您有多个软件包，每个软件包都取决于lodash@^1.0.0 ，则它们都将使用完全相同的版本。 这不仅是一种优化，而且还包括我们如何在锁文件中编码内容。

npm锁定文件是一棵树，不能保证此属性，并且多个相同的范围可能最终使用不同的版本（这很好，因为它可以通过利用Node解析规则进行更好的优化）。 在这种情况下，package-lock.json-> yarn.lock转换将是有损的，因为除了将它们合并为一个之外，我们别无选择。

另一方面，Yarn锁定文件可以相对轻松地转换为package-lock.json，因为我们的规则是您的更严格的子集（我们合并的范围可以无损地转换为树，树不能转换为无损失的合并范围）。 请注意，我只是在谈论依赖关系树本身，不熟悉您的元数据字段。

老实说，我不确定我们说的是同一件事还是完全不同的事情，我只是想澄清一下情况🙂

理想情况下，我希望警告中包括一些有关此情况的过时说明（不确定用词），并且将来的纱线版本会产生错误。 也许链接到有关此问题以及如何解决的一些详细文档。

@imsnif如果我不确信这是非CI环境中的错误（关于CI，毫无疑问-这肯定会触发错误）。 我宁愿保持警告状态，仅描述当前状态，并解释为什么它不理想。

一件好事是， @ jmorrell将能够为我们提供精确的指标，以查看警告是否足够，并在此基础上选择下一步。

当package-lock.json存在+导入纱线时，所需的最终解决方案是否是有用的错误？

是的，再加上“ CI升级到错误”模式*，我认为这是合理的第一步！

（*还不存在，我将在＃5773纱线2.0工作组中提及）

@arcanis-关于锁文件：我认为@zkat指的是（但如果我错或误解，请@zkat纠正我）是package-lock.json保存了物理树和逻辑树，而yarn.lock仅保存逻辑树。 因此，如前所述，转换package-lock.json => yarn.lock => package-lock.json将丢失物理树数据。 IMO在大多数情况下都可以，但是也有例外： 捆绑的依赖项。

我个人的观点是，两个包管理器都可以从同步其物理树的构造中受益。 从我所看到的，我们可能可以提取一些定义良好的规则，这些规则关于如何创建物理树并遵循它们（理想情况下是由所有利益相关者维护的模块）。 我认为这既可以解决兼容性问题，也可以解决yarn与捆绑的依赖项有关的一些问题，同时仍然允许每个程序包管理器保持其独特的特性。 （尽管诚然，我对这个讨论还很陌生，所以可能有些事情我没有意识到-如果我要唤醒一些熟睡的狗，我会道歉）。

但是对于当前的问题： @arcanis-在这种情况下，我将尝试仅提供一个论点来支持一揽子错误，如果您不同意，就我所关注的问题，我们可以继续进行：
尽管将其捕获到CI级别确实非常重要，但我认为错误（平均而言）比开发人员本地环境中的错误要难得多（平均）。
如果开发人员因使用错误的工具而在本地环境中遇到错误，那么他们（可能）将走得更远。 他们只是说“哎呀”，然后使用其他工具。 它可以节省大量时间，而不是在开发功能然后回溯之前将其捕获到CI上。
警告（如前所述）可能会被其他许多人吞没，如果退出状态为0，则开发人员倾向于忽略该警告。
你怎么看？

另外-在我上面描述的情况下，“外部”锁定文件可能可以理解地放置在.gitignore ，因此CI甚至没有机会了解它。 作为一个心不在a的开发人员，我可能会认为“嗯，它给了我一些关于本地环境的模糊警告，但是它通过了CI-所以这可能只是我的本地问题-嗯”

警告（如前所述）可能会被其他许多人吞没，如果退出状态为0，则开发人员倾向于忽略该警告。

我的观点是，即使我们确实有一种收集一些信息然后做出明智决定的方法，这种肯定也没有任何数据支持。 在此背景下，选择了更激进的选择，这将打破人们的工作流程在我看来有点徒劳的和潜在危害😕

另外，我认为您有点忽略了“我正在使用程序包管理器并想尝试另一个程序”的用户故事，对于所有相关人员（包管理器维护者和用户），这都非常重要。 如果人们无法轻松地从其Yarn项目中试用npm 6（或者相反，从其npm项目中尝试Yarn），那将不是很好。

我个人的观点是，两个包管理器都可以从同步其物理树的构造中受益。

这是一个不同的话题，但我不同意。 我认为有人误以为Yarn是npm，这是不正确的。 如果您想通过专用命令将项目导入另一个项目，那么我就此了，但是以无声的方式从第三方格式转换（或读取）锁文件是造成灾难的秘诀：

• 它将忽略配置文件
• 下次添加/删除软件包时，它将破坏物理树
• 软件包管理器独有的任何功能都无法使用（工作区，分辨率覆盖，链接：，...）

我的观点是，即使我们确实有一种收集一些信息然后做出明智决定的方法，这种肯定也没有任何数据支持。 在这种情况下，选择更激进的选择来破坏人们的工作流程，在我看来似乎是徒劳无益且可能有害的困惑

正确-它没有任何数据支持。 我肯定在这里猜测（对不起，如果我不强调这一点）。 虽然我们可能可以了解警告修复的趋势，但我们无法了解这对用户有多方便，以及是否有更方便的解决方案。 如果我们依赖于数据，那么除了“ Heroku部署错误率绝对没有改变”之外，我认为没有其他结果可以将我们引向整体错误解决方案。

我同意不破坏人们的工作流程非常重要。 这就是为什么我建议将该错误表示为2.0.0的重大更改，并在警告中使用措辞警告用户此情况已过时。 我也认为我们可以允许使用--force或config参数来覆盖此行为。 （我相信这也可以解决您尝试其他软件包管理器的问题？）

这是一个不同的话题，但我不同意。 我认为有人误以为Yarn是npm，这是不正确的。 如果您想通过专用命令将项目导入到另一个项目中，我将全力以赴，但是以无提示的方式从第三方格式转换（或读取）锁文件是灾难的根源

我想您在这里提出了一些重要的问题，我很想解决。 但是正如您所说，这是一个不同的主题，我不想破坏对话。 也许我们可以在另一期中讨论它？

我认为这里的对话有点脱轨，因此我想通过一些澄清和总结来整理一下：

1. 纱线和npm具有不同的分辨率和物理树创建策略，这是两个项目都存在的关键因素。
2. yarn.lock和package-lock.json文件都是在考虑特定目标的情况下创建的，据我所知，这些目标并未完全对齐，但存在一些重叠。
3. 这些目标的差异通常不会使格式优于其他格式，它们只是权衡不同的东西。

基于这些，我认为保持两种格式实际上对于创新和满足不同需求至关重要。 所需要的是确保项目可移植性，并在软件包管理器之间以最小的数据丢失，而不会将特定的软件包管理器策略强加于另一个，以允许进行免费实验。

我看到了针对其他锁定文件的确认和警告，以及正确的转换以及清晰的消息，这些消息对于双方的用户而言都具有很大的价值，它是保守的和丢失的。 因此，现在此期的问题是，对于运行yarn的用户，在其回购中具有程序包锁定文件的用户来说，最佳流程是

自动转换似乎具有潜在的危险，如果无法解决安装失败，可能会伤害某些人。 如何要求为纱线设置配置以知道具有程序包锁定文件打算在CI模式下使用？ 这是开发人员发出警告的信号，说：“我知道我在做什么，请不要试图保护我免受任何差异”。

有什么想法吗？

如何要求为纱线设置配置以知道具有程序包锁定文件打算在CI模式下使用？ 这是开发人员发出警告的信号，说：“我知道我在做什么，请不要试图保护我免受任何差异”。

@BYK-听起来不错。 还有一个补充： @arcanis在这里以及package-lock.json出现在.gitignore ）。

@arcanis如@imsnif所述：pkglock包括树的逻辑和物理布局。 通过遵循树的逻辑版本（包括我们从中进行重复数据删除的范围），您可以在没有安装或完全不运行安装程序逻辑的情况下构造一个yarn.lock内存。 只是树查找:)

从NPM 5发行说明中：

一种新的标准化锁文件功能，旨在实现跨包管理器的兼容性（package-lock.json）

NPM团队似乎在宣传package-lock.json作为通用解决方案； （从技术上）有可能加入那支力量吗？

我想提出的一种解决方案是“仅在已存在时使用package-lock.json ”。 基本上，这就是NPM从收缩包装“迁移”到锁定json文件的方式。

NPM团队似乎宣传package-lock.json作为通用解决方案。 （从技术上）有可能加入那支力量吗？

我们已经讨论过了，如果还没有，请检查线程的其余部分。 这不会在短期内发生。

我认为您有点忽略了“我正在使用软件包管理器并想尝试另一个软件包管理器”的用户故事，这对于每个参与人员都非常重要

上下文切换可能不是常事。 我前一段时间选择了Yarn，并且没有回头。 我认为最好对为什么存在锁定文件的重要性加以重视。 使它成为可以选择退出的错误，而不是将被忽略的警告。 当有人提交锁定文件时，这是有原因的。

我们的统计数据表明，大多数Yarn用户还使用npm。 混合的项目很少见，但是一个人从事多个项目是很常见的，其中一些项目是npm，一些项目是Yarn。 使问题进一步复杂化的是，直接运行npm的安装脚本是一回事。

我想使用yarn，但是我从事的大多数项目都只有package-lock.json文件。 我无法添加yarn.lock文件。 yarn import缓慢和/或损坏。 目前我的
_only_选项是抛纱并切换到npm。

我知道纱线是由纯纱线开发人员为纯纱线项目开发的。 但是我们其余的人呢？

嘿@Spongman - yarn import不应该被破坏。 现在，它应该可以为您导入package-lock.json 。 如果您遇到问题，请告诉我们！

我做了＃6103

嘿@Spongman-我在此问题中发表了评论，此特定情况是由于package-lock.json损坏。 我很高兴知道其他任何问题。

npm可以很好地使用该package-lock.json文件。 纱线需要更具弹性。

在另一期中回答了这个问题-我要求讨论移至该处，以使该期保持主题不变。 谢谢！

我正在仔细观察并参与https://github.com/yarnpkg/yarn/issues/3614 （当前为254：+1：s）。 该问题现已结束，讨论移至此处。

忽略实际挑战，到目前为止，我认为最好的UX将由顶部摘要中未提及但@thatlittlegit提及的

我认为最终目标应该是在Yarn和npm之间共享一种锁定文件格式。

这也得到@BrainBacon观点的支持：

在我看来，任何类型的项目都应指定应使用哪种程序包管理工具，这似乎很奇怪。

再次，忽略了一分钟的实际挑战，在这个线程中@iarna （和在另一个线程中的@jhabidas ）对此提出了理论上的反驳：

拥有多个积极使用的工具可以做出不同的权衡，这有很多优点，因为这意味着与使用单个通用解决方案相比，可以更好地满足用户用例。

就我个人而言，我不认为此参数适用于这种情况，就像我在其他线程（具有95：+1：s，2：-1：s）

是的，我同意，Yarn希望尽可能保持其独立空间，因此可以灵活地提供更好的体验。 例如，这就是为什么Yarn的CLI故意与NPM的CLI不兼容的原因。

但是，我认为锁定文件不在Yarn可以合理地保持独立性的空间之外。 package-lock.json和composer.lock与package.json和composer.json一起被提交到存储库。 这些不是特定于工具的文件，而是特定于项目的文件，用于指定保证可以使用该项目的确切依赖版本。

...

为了使Yarn成为有用的工具，它必须允许开发人员在其项目中遵循标准模型，因此该项目可以与工具无关。 毕竟，这就是为什么Yarn建立在package.json之上而不是其自己的独立依赖文件之上的原因。

阅读了该线程的大部分内容后，我仍然同意我的初步评估-如果Yarn继续从存储库中消耗相同的package.json依赖文件，理想情况下，它应该向存储库中发出相同的package-lock.json文件，因此存储库可以与工具无关。 如果Yarn从yarn.json而不是package.json读取其依赖项，我将不会继续指出这一点。

我相信我们应该承认这是理想的情况，无缝的用户体验。 但是，我确实了解@iarna的另一点：

我认为，单一的锁文件格式不太可能会产生结果，因为锁文件格式之间存在不同的权衡取舍，并且对于哪种最佳文件格式缺乏共识

（尽管我不同意“使两个工具能够相互理解彼此的锁文件就足够了”）。

如果绝对不可能实现允许存储库为工具不可知的理想方案（并且我看到了很多评论，说明如何以根本不同的方式构建不同的锁文件并包含不同的信息），那么看来我们似乎正走向何方美味，即：

• 如果NPM / Yarn发现对方的锁定文件（或者可能是将其变为错误的配置选项），它们将发出警告。
• 两种工具都提供了将一个锁文件转换为另一个锁文件的机制

我认为在任何情况下都不应该转换和删除对方的锁定文件。 这意味着新开发人员将永远永远从一个人转换到另一个人，然后再转换回来，这取决于开发人员恰好使用的工具（假设有太多人使用git commit -a提交）。

我也不同意@imsnif的观点：

我认为单个软件包同时具有package-lock.json和yarn.lock文件没有充分的理由。

我认为决定开发人员在其计算机或生产环境中运行的软件是一种冒昧。 至少有礼貌的是，不要比您需要的限制更多。 如果您的项目仅由开发人员团队运行，并且他们都运行完全相同的软件，那就太好了。 但是由于某种原因，您可能会有一个发现使用NPM比使用Yarn容易得多的开发人员。 特别是如果您制作开源软件，则希望使社区成员尽可能容易地启动和运行。 鉴于NPM和Yarn只是用于从package.json安装相同依赖项的工具，它们应该可以正常工作。 开发人员应该能够看到package.json ，并拥有一个解释它的工具，而无需进一步担心。 在此锁定文件冲突单独出现之前曾经是这种情况。

嘿@nottrobin-我想我知道您来自哪里。 如果我们忽略了实际挑战和哲学差异，那么，如果各种工具的用户都使用相同的锁文件，那肯定会更好（当然，这是我个人的看法）。

但是，由于我们不能忽略所说的实际挑战，并且似乎大多数都同意哲学上的分歧，所以我认为我们所达成的妥协（您在上面概述的妥协）“足够好”。

请注意，上述折衷方案中的一个隐含假设是，工具选择是根据项目而不是开发人员的机器或生产环境选择的。

请注意，上述折衷方案中的一个隐含假设是，工具选择是根据项目而不是开发人员的机器或生产环境选择的。

是的，我认为这是我最担心的问题-尽管我认为在上面概述的方案中，仍然有可能同时支持Yarn和NPM的项目。

我确实认为，最终，如果两个项目放弃了试图使一个项目与工具无关的任务，那么实际上他们应该停止共享依赖文件。 纱线应切换为读取yarn.json而不是package.json 。 其他任何事情都只是混乱和混乱。

如果npm锁定文件已经具有Yarn锁定文件支持的依赖关系的超集，为什么不在Yarn中同时支持两者？ Yarn可以切换到package.json，并且将来可以添加Yarn可能需要的任何其他字段（类似于Inkscape之类的SVG编辑器管理编​​辑器元数据的方式）。 然后，Yarn可以具有与npm相同的依赖项格式，并与yarn.lock向后兼容，从而将npm锁定文件转换为Yarn在内存中所需的任何结构。

我确实认为，最终，如果两个项目放弃了试图使一个项目与工具无关的任务，那么实际上他们应该停止共享依赖文件。 纱线应切换为读取yarn.json而不是package.json 。 其他任何事情都只是混乱和混乱。

也许，也许不是。 当然，这将需要对工具（纱线）进行大规模的更换。 具有更直接和可衡量利益的不太根本的变更已被转移。

我并不是说这是一个坏主意，我只是说我不觉得这是一个实际的主意。

我并不是说这是一个坏主意，我只是说我不觉得这是一个实际的主意。

我同意这似乎是一个很大的问题。 但是我要说的是，这似乎是该项目的关键问题。

到目前为止，Yarn一直是开发人员可以选择使用的工具，而不是NPM来为package.json任何项目安装Node依赖项。 现在，正如您所指出的，它要求项目在Yarn和NPM之间进行显式选择。 这是一个巨大的变化，不应偶然做出。 这是打电话的关键时刻。

我认为有3种前进方式：

1. 通过在所有项目级界面上找到使Yarn与NPM对齐的方法，继续替代NPM（对锁文件进行标准化）
2. 通过使用明显不同的项目级别界面（例如yarn.json和yarn.lock ）故意与NPM脱节
3. 加倍提供一半的NPM接口和另一半不同的接口。 这实际上与第2点相同，但是大多数人都喜欢第1点。

我相信这里的第三个选项会混淆整个Node空间，并大大削弱这两个工具。

它仍然可以向后兼容。 Yarn可能只有一个内置的npm lockfile转换器，因此当它看到package-lock.json时，它将保留在那里并将其转换为内存中的yarn.lock格式。 据我所知，npm无法做到这一点，因为Yarn的锁文件所包含的信息少于npm的信息，所以我认为Yarn最好使用npm进行标准化。

@nottrobin我认为您在分析中基本上是正确的，但是：

现在，正如您所指出的，它要求项目在Yarn和NPM之间进行显式选择。 这是一个巨大的变化，不应偶然做出。

我认为情况一直如此，或者至少可以说是Yarn最初被吹捧的主要好处：依赖树的可复制性。 您可以检入yarn.lock ，但是如果其他开发人员在不遵守该锁定文件的情况下添加/删除依赖项，这实际上是没有用的。

@nottrobin-我同意@Vinnl。 如上所述，虽然我不想告诉任何人应该如何工作，但我认为同时使用yarn和npm在同一项目中安装依赖项是一种反模式。

尽管从技术上讲这两种工具都可以投入大量工作来完成这项工作，但我认为这不是维护人员应该鼓励的。 拥有可互换的锁定文件还有许多其他好处（如不同线程中的各种讨论所示），但是我个人认为这不是其中之一。

但是，如果其他开发人员在不遵守该锁定文件的情况下添加/删除依赖项，那实际上是没有用的。

是的，我想从某种程度上讲Yarn从一开始就处在浑水之中- yarn.lock的存在已经意味着它部分地拥有自己的界面。 我认为这总是一件很麻烦的事情，这符合Yarn希望人们从NPM过渡到Yarn，但又不能退缩的目的。

但这是一个让我为自己的项目做的决定，因为至少我知道NPM仍然得到了完全的支持-由于它最初并未提供锁定功能，因此它将像往常一样继续工作。

现在已更改，因为NPM确实锁定了依赖性。 如果我选择将项目绑定到Yarn，我现在将保持yarn.lock为最新状态，而不是package-lock.json ，因此不再有人可以在我的计算机上有效使用NPM项目。

听起来您是在说纱线不再打算替代npm吗？ 只能用于纯纱线项目吗？

我认为是这样的话，那么您应该欠大家在纱线首页上清楚地说明这一事实-使用this或npm，不要同时使用两者。

听起来您是在说纱线不再打算替代npm吗？

从来没有。 该界面有点模仿npm，以使用户更容易理解如何使用它，但是从一开始，有些事情就有所不同。 有人认为这是直接替换的主要原因是npm只是缺少要比较的功能。

既然npm正在赶上某个方面并决定以不同的方式实施事情，它只是开始表明我们有不同的方法并做出了不同的决策（例如，最近实施的npm脱机镜像功能与我们现有的脱机镜像功能不兼容）。 简而言之：它从来都不是“安全的”，只是偶然地起作用。

我认为是这样的话，那么您应该欠大家在纱线首页上清楚地说明这一事实-使用this或npm，不要同时使用两者。

事实上，我们确实有迁移说明。 您的评论使我注意到，不幸的是，它包含

从来没有

嗯...那么，您需要与您的营销人员交谈。 https://yarnpkg.com/lang/zh-CN/docs/

纱线直接与npm的许多功能（包括其包元数据格式）进行互操作，从而可以轻松进行迁移。

我们没有营销人员，但我们接受不错的PR

在这种特殊情况下，听起来并不太错。 我们实现了许多功能的互操作，但并非全部都互操作，并且在大多数情况下，迁移过程都很轻松（更糟糕的是，距离yarn import ）。

迁移无痛

我对迁移不是很感兴趣。 我正在寻找此处承诺的内容（这些人肯定有营销人员）： https ://code.fb.com/web/yarn-a-new-package-manager-for-javascript/

它具有与现有工作流程相同的功能集，同时可以更快，更安全，更可靠地运行。

今天的纱线不是那样。

AFAICT这里有4类用户：

• 那些只在他们的项目中使用yarn的人，
• 那些购买了facbook销售产品（上面）但还没有遇到这些锁定问题的企业，
• 那些在需要时通过手动转换锁定文件或使用其他黑客使其正常工作来解决不兼容问题的方法，
• 那些刚刚放弃纱线而又转回npm的人。

我真的不想进入最后一个类别，但是似乎这就是我被推崇的地方。

@Spongman是什么阻止了您进入最后一个？ 我们可能可以解决它;）

@Spongman我不喜欢Yarn，所以我可能会更用语是没有

（我想您可能无法编辑博客文章，但是网站在这里可能是最重要的。）

从@imsnif和@arcanis的回复中可以看出，这里的官方立场似乎是，Yarn从未打算与NPM继续无缝地合作。

但是我完全同意@Spongman的看法，这就是Yarn给人的印象，我真的不认为那是偶然的。 那是它的天才-您可以提高速度，安全性等，同时仍然完全支持官方NPM标准。

无论哪种情况，这个问题都使Yarn在此问题上的立场比以前更加明确，当然，Yarn的维护者可以选择沿任何方向发展。

但是我认为您是在大幅度地低估了使用Yarn的人数，因为他们认为Yarn与NPM保持了兼容性（在项目级别），否则就不会做出任何改变。 我相信https://github.com/yarnpkg/yarn/issues/3614上的254：+1：s和10： heart：s以及“我是否应该提交yarn.lock和package-lock.json文件？ ”对此非常清楚。

如果Yarn在这方面放弃任何责任，我认为它将不仅失去@Spongman和我的团队，而且还会失去许多其他人。

坦白说，我真的不理解仅使用Yarn或仅使用npm所遇到的问题。 您的意思基本上是“嘿，我不能强迫我的团队使用Yarn，所以我要强迫他们使用npm”。 这对我来说毫无意义。 如果使用Yarn的功能，则使每个人都使用Yarn，如果要使用npm功能，则使每个人都使用npm。 就这么简单。

两者之间的任何关系都意味着至少您的团队中的构建不一致，这与前面提到的Yarn的前提背道而驰。 您的一位工程师可以开始使用工作空间，并且可以工作，但是会在npm上中断。 与脱机镜像相同。 依赖项解析也一样​​。 更糟糕的是，由于npm完全不了解某些字段，因此它会默默地做错事。

至于交流，fb博客文章中没有提及直接替代品。 让我引用引入纱线的部分。 从字面上说是取代了工作流程。 我猜您对“仍然与npm注册表兼容”感到困惑，这是您应该带给npm的公平点，而不是给我们（这里有npm cli，npm注册表，当然还有npm Inc本身）。

Yarn是一个新的程序包管理器，它替换了npm客户端或其他程序包管理器的现有工作流程，同时仍与npm注册表兼容。

是什么阻止了您进入最后一个？ 我们可能可以解决它;）

@zkat很有帮助，谢谢。

@nottrobin-我不能代表yarn的初衷，因为当时我不在。 但是，我在具有数十个存储库的纱线/ npm混合环境中工作。

我可以说，这是非常清楚涉及当时所有的开发商纱/ NPM的选择是每个回购的选择，就像快递/高致病性禽流感的选择，mobx /终极版等，这成为为更清楚NPM @ 5推出了自己的锁定文件格式，一些开发人员决定开始在新的存储库中使用它。

当开发人员使用错误的工具安装依赖项时，即使在npm @ 5之前，也会造成混乱，因为该依赖项不会始终被锁定。 它在我们的各种环境中引起了问题，所有参与者都非常清楚这是一个错误*。

我意识到这可能会造成混淆-并且我理解这可能并非每个人都没有自己的过错，但并非所有人都100％明白这一点，但是我认为为应对这种误解而大刀阔斧地更改工具是不正确的。 我的看法是，纱线是按回购而不是按包装盒替代npm的下降。

*当然，对于多个潜在的错误可能性，在人工水平上而不是在技术水平上，不理想的是使用混合纱线/ npm工具的多个非工作空间回购的特定情况，并且最终将其修复。 我在这里使用此示例说明，如果正确使用，这两个工具可以并排工作。

坦白说，我真的不理解仅使用Yarn或仅使用npm所遇到的问题。

是的，您@arcanis和@imsnif明确表示您不理解。 我要说的唯一一点是，很多人（看：+1：s）做出相同的“ mis-”解释，并希望Yarn与NPM一起工作，无论您是否理解。 如果Yarn不是我们的工具，那就去吧。

（最后一点- @imsnif ，将用于安装Node依赖项的工具与Express，Hap，Mobx和Redux等项目选择进行比较是完全荒谬的。这些是您应用程序的基本特征。如果看不到明显的区别，难怪你不明白我的意思。）

无论如何，我现在完成了。 我想我已经尽力了。

对于开源项目来说，从来没有强迫“团队”使用yarn或npm的问题。 这是对每个人最方便的问题。 因此，在现实世界中，npm是王者，除非纱线可以在npm世界中发挥出色，否则它就死定了。

^这

恐怕这也是一个误解。 在过去的一年中，Yarn从向npm注册中心提交的请求总数的20％增长到4月的40％ 。 上次我听到统计信息时（直接来自npm人士，因为npm注册中心转到Cloudflare时我们的统计信息最近失效了），大约占请求的48％。 在现实世界中，Yarn和npm并存，简单而简单。

现在，我很想知道是否可以回到当前的主题：谁在安装时检测到package-lock.json文件时愿意写PR来写警告？ 谢谢。

psst @arcanis - https://github.com/yarnpkg/yarn/pull/5920

很棒：heart_eyes：

在此与您在yarn import上的工作之间，我们可以解决这个问题吗？

我以为我们会等待@jmorrell向我们提供一些有关如何影响Heroku问题的​​统计信息，以便我们可以决定这是否足够，或者我们想更改某些内容（警告/错误等）。

编辑：afaik该警告尚未发布，因此我们仍有时间等待。

恐怕这也是一个误解。

为何如此？ npm的通信量告诉您该项目是否是开源的。

一个更准确的评估是计算哪个github项目具有（yarn.lock，package-lock.json）的0.1或2。 我个人已经_never_在github上看到了一个开源项目（任何大小），它具有yarn.lock文件和_no_ package-lock.json（明显的除外）。

IMO如果您要保留单独的锁定文件，则两个软件包管理器都应检测另一个的锁定文件和ERROR（可能带有覆盖标志）。

全部-请您关注我们的话题，并让所有与非直接相关的评论脱机（例如，我们的Discord频道）。 有很多人订阅此线程，公平地说，我觉得npm <> yarn讨论不属于这里。 谢谢！

我尚未阅读完整内容，但应该至少通知IHMO用户存在歧义：

如果npm看到yarn.lock文件，则npm应该打印如下内容：
“警告：该项目似乎使用yarn，也许您应该使用'yarn'而不​​是'npm install'”

如果yarn看到package-lock.json文件，那么yarn应该打印如下内容：
“警告：该项目似乎使用npm，也许您应该使用'npm install'而不是'yarn'”

就像上面建议的那样，一种“偏爱”包管理器的方法（在package.json中）。

我可以说，当时所有参与其中的开发人员都非常清楚，纱线/ npm的选择是每个回购选择，就像Express / hapi，mobx / redux等的选择一样。

我一点都不清楚。 直到现在，我还认为这是开发人员本地化的选择，并且多个开发人员可以使用他们喜欢的任何一个在一个存储库中共存，同时（更方便一点）只使用一个即可。 虽然express / hapi等示例很好，但要明确指出这不是一个选择。 这应该具有更大的可见性。

在package.json中添加一个字段以指示项目应使用哪个包管理器

"package-manager": "yarn"

我认为这是最好的解决方案，因为它已在所有软件包管理器中实施。

然后，如果在错误的项目上调用了软件包管理器，则软件包管理器必须100％拒绝继续进行操作，就像您在需要redux但随后尝试在其上调用mobx函数时会遇到错误一样。 他们应该发出错误而不是警告，并通知用户如何继续使用正确的程序包管理器。

在package.json中添加一个字段以指示项目应使用哪个包管理器
"package-manager": "yarn"

我认为这是最好的解决方案，因为它已在所有软件包管理器中实施。

如果您希望npm考虑这一点，我鼓励您在适当的场所进行讨论，但我会说我不喜欢这个方向。 我希望看到软件包管理器之间的融合而不是差异。

我建议不要使用一些新的“ package-manager”字段，而建议使用已有的已有技术的现有engines节。

yarn和npm文档都提到了engines.npm和engines.yarn用法，以指定预期使用的每个版本。 如果纱线版本不满足engines.yarn ，纱线甚至会出错。

https://yarnpkg.com/zh-CN/docs/package-json#engines-
https://docs.npmjs.com/files/package.json#engines

即使npm或yarn不检查“竞争”管理器的engines （这都很好），使用此字段仍然是与其他开发人员进行交流的好方法，而预期使用该管理器。 （如果package-lock.json或yarn.lock的存在不足以提供线索）

我希望看到软件包管理器之间的融合而不是差异。

同意要么收敛，要么拒绝。

但是目前模棱两可，错误的中间立场是有害的。

我仍然认为，只要在其他人的锁定文件存在的情况下抛出错误，对现有项目的摩擦就最少。

如果您希望npm考虑这一点，建议您在适当的地点进行讨论

谢谢，我刚刚注册。 这个方向上有一个最新的线程： https :

我的投票是赞成使句号错误而不是仅仅警告，所以不确定是否应该在启动新线程的那条后面。

我希望看到软件包管理器之间的融合而不是差异。

同样在这里。 尽管它们目前不兼容，但是这种差异已经发生，并且已经给许多用户和项目造成摩擦。

团队之间进一步的讨论产生的任何融合都将需要时间。 当它到达时，可以消除建议的错误，用户可以毫不费力地切换和混合软件包管理器。

现在添加错误可以避免进一步的混乱，并且不会停止朝融合方向的努力。

我建议不要使用某些新的“ package-manager”字段，而建议使用已经具有现有技术的现有引擎节。

听起来很合理。 我不了解检测不兼容的程序包管理器是否存在的任何特定方法。

为了补充说明，我的用例尤其是gatsbyjs。 这种情况与@gaearon在此处报告的情况完全相同：

对于创建React App用户来说，这非常令人困惑，因为他们的项目是使用Yarn创建的（如果系统上存在Yarn），但是随后他们遵循某个库的文档，告诉他们进行npm安装，这使整个树都被炸掉。

为了避免此问题，即使gatsby使用yarn，它也会向默认的启动器添加package-lock.json 。 但是随后，用户最终都同时拥有了锁定文件并开始看到警告。 删除其中之一很容易，但是却混淆了入职体验。

谢谢各位的意见。

@jmorrell - https://github.com/yarnpkg/yarn/pull/5920已于1.9.2于7月25日发布。已经过去了一个多月，我知道时间不多了（而且肯定不会）每个人都进行了升级）-但是从那时起，您是否可以就Heroku上的双锁文件错误分享一些见解？

@imsnif感谢您的电子邮件提醒！ 抱歉，错过了这里的更新。

这是2018年每周经历此特定故障的应用程序数量的图表。

（我已经编辑了y比例尺，但这代表了100个开发人员并显示了趋势）

1. 7月的下降来自与S3无关的问题

2. 从7月25日之后的趋势来看，该警告似乎对经历此错误的人数产生了重大影响。 我对这种转变的幅度感到有些惊讶。

@jmorrell-真的很棒！
我承认我对此也感到很惊讶。

我认为（在纱线方面）此问题可以视为已解决。 你同意吗？

我仍然认为删除package-lock.json来修复错误的建议具有误导性-这通常会导致使用一组不同的软件包版本，并且（再次）通常会导致不兼容和损坏。 同样，该建议仅对那些决定使用哪个程序包管理器的人有用。 遵循此建议的一般贡献者也会遇到问题。

IMO如果package-lock.json存在，并且yarn不能保证安装的版本与npm安装版本相同，则它应该失败并显示错误。

再次感谢您输入@Spongman。 我觉得在我们上面的（很长）线程中对此进行了充分的讨论，并且我认为重新启动它没有意义。 我想我们都了解您的立场。 感谢您的参与。

除非@jmorrell在

@imsnif从9月至今（9月1日至9月20日）采用不同的方式查看故障，这仍然是Node在Heroku上构建失败的第一大原因。 它发生的次数是下一个最常见的失败案例的两倍：package.json是无效的JSON。 再次编辑准确的数字，这就是它叠加其他问题的方式。

我从npm上没有看到任何动静，因此我将在其中创建一个PR并添加警告，以确保它被接受。

我认为（在纱线方面）此问题可以视为已解决。 你同意吗？

我认为这尚未为用户解决，并且用户体验仍然不佳。 但是我可以看到，一旦npm改变，数字也会如何变化，这也会给用户提供反馈。

无论您是要结束此操作还是进行其他更改，我都会由您决定。 如果这对用户来说仍然是一个大问题，我很乐意在几个月后打开一个新期刊。

@jmorrell-看到这个问题吸引了很多注意力，并且对话不断重启，甚至不断重复，我认为现在最好使用我们掌握的信息来结束它。

如果在npm也提供警告的情况下，我们仍然看到问题，我肯定愿意再次开始错误讨论（或研究其他解决方案）。 请在这种情况下亲自对我执行ping操作。

感谢您提出来，做出贡献并进行所有这些更改！ 我个人觉得这个问题过后纱线会更好。