yarn 🚀 - 不要警告不兼容的可选依赖项

似乎是对警告的适当使用。

ghost 于 2017-06-28

👎59

修复发出警告的东西而不是仅仅隐藏警告会更好吗？

wtgtybhertgeghgtwtg 于 2017-06-28

👎21 👍1

@wtgtybhertgeghgtwtg

您所说的“修复”是什么意思？如https://github.com/npm/npm/issues/11632中所述，一切都按预期进行。有些软件包特别依赖于macOS上的fsevents （因为它提供了卓越的体验），但是又依赖于Windows / Linux上的其他行为。 fsevents与Windows不兼容的事实不应该向用户显示：它只是依赖项的特定于平台的实现细节。那里的用户没有什么可采取的行动（也没有什么值得惊慌的）。

gaearon 于 2017-06-28

👍61

我要说，要求依赖关系并为特定的操作系统添加二进制文件不应该是这样的。
我确定还有其他软件包会弹出此问题，但fsevents是最主要的软件包，在babel ， webpack ，您的create-react-app ，我很快就会确定sane和jest 。我认为，由于一个软件包的缺点，找到一个更好的文件监视解决方案而不是更改软件包管理器的行为会更有效率。

wtgtybhertgeghgtwtg 于 2017-06-28

👎13

如果您对使用fsevents （或fsevents本身）的程序包有其他建议，我想听听！我认为拥有特定于操作系统的软件包没有任何“错误”。它解决了一个实际问题，并且某些问题是特定于平台的。

gaearon 于 2017-06-28

👍1

看来意见分歧。
我认为对不可采取行动的警告可能会令人讨厌。
另一方面，类似的警告（例如“此模块不适用于Node.js <4”）非常有用。
人们可以打开禁用警告的设置吗？

bestander 于 2017-06-29

👍1

@gaearon给定这是一个开放源代码回购，PR如何添加CLI标志以按日志级别禁止显示。在您所引用的软件包中写下下游问题是非常不正确的，无论它是高级计算机还是仅35美元的RPi都可以完成大多数相同的工作。

ghost 于 2017-06-29

👎4

@jhabdas

PR如何添加CLI标志以按日志级别禁止显示

我本来希望发送PR的，但是像@bestander一样，我也全职维护其他开放源代码项目，但是不幸的是没有时间来使用此特定功能。我提出了一个问题来讨论是否可取。

在您所引用的软件包中写下下游问题是非常不正确的，无论它是高级计算机还是仅35美元的RPi都可以完成大多数相同的工作。

我不明白这个评论。我不建议“解决下游问题”。 fsevents没有做错任何事情。 它想表达它仅在macOS上有用，而在其他系统上不存在。其他软件包，例如webpack ，想要表示他们想在macOS上使用fsevents ，但是想在其他系统上跳过它。这正是yarn和npm都在做的事情。

一切都已经按预期工作，除了npm和yarn还会打印一条看起来很吓人但实际上并不表示问题的消息。但是，用户无需担心，因为一切都按预期进行。因此，我的观点是，在没有任何错误的情况下停止吓users用户会很好。

对不起，如果我不太清楚。我现在可以看到这比我预期的更具争议性。那我们就不要这样做了。我不会在这座山上死去。 😛

gaearon 于 2017-06-29

👍13

另一方面，类似的警告（例如“此模块不适用于Node.js <4”）非常有用。

...但这是可行的–您可以升级Node.js版本。

glen-84 于 2017-06-29

👍13

...但这是可行的–您可以升级Node.js版本。

操作系统限制也可能是可行的。
我想问题是，是否值得在每次在Mac上而不是Mac上安装IO工具时显示相同的警告，我认为应该给Windows用户一个机会，让他们在依赖项为可选时不显示它们。

我将重新开放，似乎值得讨论更多。

bestander 于 2017-06-29

👍4

我们可能会将其降级为“信息”日志级别（并引入类似于npm的日志级别的概念）。

gaearon 于 2017-06-30

👍5

@gearon能请您提供两个免费的测试用例吗？我阅读了详细信息并听到了建议。但是，我想亲自考虑一下您认为对于初学者来说令人恐惧的经历，这些经历“几乎永远不会付诸实践”。您在上面提到了Webpack。对我而言，Webpack本身令人恐惧，因此我不使用它。如果在开发过程中始终关注正确的功能集，那么纱线可以做很多事情。这真的是您认为可以帮助实现这些目标的建议，还是您在爬别人的山？

ghost 于 2017-06-30

👎10

我遇到的情况与@gaearon所描述的情况类似：我收到有关它们自己使用较旧依赖关系的依赖关系的警告，我猜他们只是还没有升级？

当我运行yarn upgrade我一开始就得到了：

warning gulp > vinyl-fs > glob-stream > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected] ...

但是，当我查看下面的列表时，这些依赖关系是最新的。

我同意@gaearon ，看到警告特别让我感到恐惧，因为我对使用Node不太熟悉，并且已经从使用npm迁移到Yarn。但是看到警告消息也有点_misleading_，因为它暗示我可以解决此问题。

我认为这些警告应该成为友好的信息，或者根本不显示。

dmbdesignpdx 于 2017-07-07

但是，使用不安全的依赖项应发出警告。

wtgtybhertgeghgtwtg 于 2017-07-07

我们为什么谈论_scary_。这是软件开发，而不是幼儿园。

ghost 于 2017-07-07

👎32 😄5 👍2

@wtgtybhertgeghgtwtg使我感到a）不是_my_错误，错误不是我的错误，并且b）去哪里看看该问题已解决。这类信息可以使用户免于试图弄清楚到底出了什么问题的麻烦。

dmbdesignpdx 于 2017-07-07

首先改善信息，发送公关的好主意

2017年7月7日14：08，Daniel Blake [email protected]写道：

@wtgtybhertgeghgtwtg https://github.com/wtgtybhertgeghgtwtg抛出什么
我的意思是警告要求我更新无法更新的内容。
即使在这种情况下，我也不是使用不安全依赖项的人（我
我认为您的观点，并同意应该是一个警告；但是我
认为可以用措辞来提供更多信息。像这样简单
“ [[dependency_A]使用的是过时的[dependency_B]” —我马上就会知道
蝙蝠a）不是我的错，错误不在我的末端，并且
b）去哪里看问题是否已经解决。那种
信息可以使用户免于试图找出麻烦的麻烦
他们到底怎么了。
—
您收到此消息是因为您修改了打开/关闭状态。
直接回复此电子邮件，在GitHub上查看
https://github.com/yarnpkg/yarn/issues/3738#issuecomment-313793331或静音
线程
https://github.com/notifications/unsubscribe-auth/ACBdWI1Ks6bSYH_BStzm_b3-ne3bUMT3ks5sLp5PgaJpZM4OGrsi
。

bestander 于 2017-07-07

使我感到震惊的是，警告要求我更新无法更新的内容。

如果您使用的是依赖项，那么您肯定拥有它以及它引入的所有内容，并且能够分叉和改进它附带的任何内容。如果它困扰您，那也许不值得使用。

ghost 于 2017-07-07

👎21 👍2

虽然我会说

warning gulp > vinyl-fs > glob-stream > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected] ...

告诉您您需要了解的内容，我同意可以用某种措辞将其概括起来更好。

wtgtybhertgeghgtwtg 于 2017-07-07

我们可以让这个问题集中在一个特定案例上吗？我不希望这变成所有可能出现的警告的自行车棚。

我报告了一个特别的警告，其中原则上不可能“解决”该问题，即使在传递依赖项中也是如此。一切都按预期工作。

本期中描述的其他情况显示了合法的问题，需要通过传递依赖项进行报告和解决。我认为这与我描述的问题不同。如果您对它们有强烈的感觉，请提出新的问题。

gaearon 于 2017-07-08

👍22

我不希望这变成所有可能出现的警告的自行车棚。

如果相关，对话应该就在这里。请注意未解决问题的数量，这是一个增强请求，而不是错误。

ghost 于 2017-07-08

👎23

听起来不错。我将退订，但我希望以后的讨论继续集中讨论。感谢您的参与！

gaearon 于 2017-07-08

👍4

维护者，请关闭此窗口。没有人可以遵循。

ghost 于 2017-07-08

👎34

您能提供两个免费的测试用例吗？

如果在开发过程中始终关注正确的功能集，那么纱线可以做很多事情。

请注意未解决问题的数量，这是一个增强请求，而不是错误。

维护者，请关闭此窗口。

@jhabdas ，感谢您为让我在这个问题上投入更多时间而付出的努力，并指出Yarn团队有足够的力量，但没有必要继续重申这一点。这不是一个非常友好的行为。

我很抱歉，但是正如我之前已经说过的，我无法真正花时间解决这个问题。我相信Yarn的维护者可以在优先级方面做出正确的选择。如果他们认为该问题的优先级太低，他们理应忽略或关闭它。

如果我误会了，请原谅，您正在维护此存储库。在这种情况下，请随时关闭此问题。

但是，我想亲自考虑一下您认为对于初学者来说令人恐惧的经历，这些经历“几乎永远不会付诸实践”。

安装create-react-app然后运行create-react-app myapp将在安装过程中产生警告：

warning [email protected]: The platform "win32" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.

npm警告甚至更可怕：

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/react-scripts/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules/react-scripts/node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

幸运的是，npm让我们指定了日志级别，而Yarn没有。不幸的是，因此，我们不得不忽略所有npm警告。

为什么警告此问题？

对于像您这样有经验的用户，这不是问题。但是对于许多人来说，Create React App是React和npm生态系统的切入点。对于某些人来说，这是Web开发的切入点。

他们不知道什么是fsevents 。该消息显示为Create React App与Windows不兼容。这是他们的外卖。这是伟大的，如果一切正常后，但如果东西坏了，他们并不总是因为他们的想法，这不是应该感谢这些警告报告工作的问题。我正在通过这项提议来消除这种印象。

我们为什么要谈论恐怖。这是软件开发，而不是幼儿园。

人们只在幼儿园害怕的假设使我感到困惑。人们一生中都会害怕很多事情。这包括焦虑之类的精神疾病和其他恐惧（例如，担心自己的工作能力不足）。

它似乎与JavaScript工具无关，但实际上并非如此。这里有两个独立的问题：

不清楚的不可行的警告使人们感到焦虑。他们使他们对工具的信任度降低，并且使他们感到困惑，即使他们没有做错什么。这有助于凯西•塞拉（Kathy Sierra）很好地描述了
不可操作的警告噪音使人们逐渐形成警告的盲点。人们学会忽略它们。每个无法采取行动的警告都会导致这一费用。我们已经看到使用不同的工具（不仅是纱线）发生了很多次。这是“哭狼的男孩”的情景。结果，将来人们无法诊断问题并浪费他们和维护人员的时间，因为他们错过了不重要的警告中的一个重要警告。

我希望这可以弄清为什么我认为值得解决。但是，我不会进一步参与此讨论，因为您似乎非常热衷于否决此提案，并且我不愿意投入更多的个人精力与您讨论该提案。

gaearon 于 2017-07-08

👍57 ❤3

这就是我希望得出的@gaearon信息的深度。感谢您抽出宝贵的时间来解释，因为您对学习者的同情心似乎很闪耀，这值得称赞。

我觉得重要的是我们要教给学习者自己钓鱼。有时，这意味着不保护他们免受恐惧困扰，而是鼓励他们直面恐惧。

在fsevents警告的情况下，即使作为可选依赖项，也应鼓励学习者注意警告并寻求理解。否则它们将不会增长。

例如，对Stack Overflow的快速搜索提供了以下解决上述警告消息的解决方案： https :

如果需要考虑认知开销，那么我将鼓励个人寻求其他工具来创建其单页应用程序，或者在更适合于获得Web基础知识的

ghost 于 2017-07-09

👎49 😕6

@ glen-84您是否愿意分享您的意见，或者只是挥手致意？

当然。

显示有关不可操作且不会引起任何问题的警告，将导致：
- 开发人员浪费的时间首先必须找出原因，然后每次都必须忽略它（而忽略警告是一件坏事）
- Yarn / npm开发人员浪费时间，必须解释为什么会发生
- 下游工具错误
- 等等
如果您将npm问题的票数相加，则将有150个用户同意。
从理论上讲，npm开发人员已经接受了此更改。

我否决了您的两条评论，因为IMO他们对此讨论没有任何价值。

glen-84 于 2017-07-09

👍29

我同意无法采取行动的警告是没有用的，它们也可能不必要地令人恐惧/嘈杂/。让我们按照@bestander的建议使用@dmbdesignpdx的建议吗？

公关的欢迎。

BYK 于 2017-07-09

开发人员浪费的时间首先必须找出原因，然后每次都必须忽略它（而忽略警告是一件坏事）

您不会忽略它。您了解发生这种情况的原因并采取行动。有时，这将导致回购中的另一个工具集或问题，如@Vanuan在相关NPM问题中所建议的

Yarn / npm开发人员浪费时间，必须解释为什么会发生

解决来自单个存储库或程序包管理器的问题不是Yarn的责任。 NPM并不是唯一的包装商。我个人更希望看到Yarn成长为取代Composer并填补空缺的Bower刚离开社区，而不是被红鲱鱼分散注意力。

如果您将npm问题的票数相加，则将有150个用户同意。

那就是广告人群。委员会的设计永远无法为任何人带来成功。

ghost 于 2017-07-09

👎18

由于进行了讨论，因此删除了cat-discusson标签，现在我们可以执行一项可行的操作：通过声明哪个软件包依赖于另一个不赞成使用的软件包，使警告更加有用。

@jhabdas我认为我们同意“学习”和“采取行动”部分。我们似乎不太同意的部分是我们如何做到这一点以及是否要负yarn的责任。目前，我认为纱线对用户越有帮助，效果越好。就是说，我不会高度优先考虑将资源用于更重要的修复和更新，因此，我们请社区来进行PR。

如果有人想进一步讨论这个问题，让我们将其移至Discord。您可以直接在这里ping我，以引起我的注意。 💓

BYK 于 2017-07-09

👍3

您了解发生的原因并采取行动

我们应该采取什么行动？

解决来自单个存储库或程序包管理器的问题不是Yarn的责任。

是Yarn和npm开发人员会反复看到有关此问题的报告，并且不得不花时间进行不必要的问题分类，而不是研究新功能和错误修复。

那就是广告人群。委员会的设计永远无法为任何人带来成功。

这就是我们现在所拥有的一切，如果您不同意这些更改，那么您对此问题的不赞成票将有助于维护者进行决策。

glen-84 于 2017-07-09

好吧，@ glen-84友善地提醒我，最初的问题与子依赖关系和信息性消息无关，而仅仅是警告不能在特定平台上安装的软件包。

因此，现在针对此特定故障单的操作是将其从警告降低为信息或调试，因为它不会增加价值。有异议吗将另一部分移至＃3869。

BYK 于 2017-07-09

👍9

@gaearon进行了无单元测试的单行代码更改，以解决此问题。请记住这一点。

ghost 于 2017-07-12

👎21 😄1

@jhabdas我已经在PR中回答了。这是我的理念https://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565，但是如果您认为包兼容性或该部分特别需要一些测试，请打开请求请求，并在此先感谢:)

voxsim 于 2017-07-12

👍4

我相信您的良好判断力，但我相信我会尽全力。但是没关系。我想发送信息给其他人，以了解更改一行代码如何避免整个线程。有时候，行动胜于雄辩。干杯。

ghost 于 2017-07-12

👎21

非常感谢您@jhabdas的贡献，我想提醒您我们的行为准则，特别是以下各项：

使用欢迎和包容的语言
尊重不同的观点和经验
对其他社区成员表示同情

BYK 于 2017-07-12

👍25

我最诚挚的歉意。我将审查行为准则，并努力做一个更好的社区公民。感谢您为我指出正确的方向，@ BYK。

ghost 于 2017-07-12

❤4 👍2

感谢您解决此问题。 🙇

这是NPM中票数最高的问题，并引起了实际的问题，但是经过1.5年的不解决之后，他们的机器人才因为太老而自动关闭了它！

这种项目管理是我改用Yarn的原因之一。

看到此修复程序有多么容易，这使它浪费了很多时间和精力。 😢

谢谢！

jods4 于 2017-07-14

您好，感谢您为此付出的所有努力。更好的是它将现在放在我的stdout上，而不是stderror;）。然而，即使是信息水平也将带来大量的人。一小时的阅读相关问题后，他们可获得的唯一输出是他们暂时需要使用它（不使用babel），并且可以通过可选的依赖项进行特定于平台的优化，但是成本为软件包管理器对用户的警告。我支持仅在调试级别输出此结果。

kubino 于 2017-07-18

👍2

@kubino这是一些很好的反馈，谢谢！我们知道将其移至info不会一劳永逸地解决它。为此， @ jhabdas实际上花费了一些时间使其变得更好和通用，并提交了RFC 。您是否有兴趣在此提供反馈，并让我们知道RFC是否可以解决您的问题？

BYK 于 2017-07-18

@BYK感谢您对此仍然感兴趣。我远不是专家，也许我弄错了。您将我指向RFC，标题为“使不赞成使用的子包警告更具信息性”。我认为默认情况下向用户传递DEPRECATED警告是正确的（尽管有一种方法可以抑制特定的软件包警告可能会很好）。
我关心的是OPTIONAL依赖项，该依赖项仅作为某些特定平台的优化，在那里我看到污染非常少的价值，否则会产生如此漂亮的干净Yarn输出。但是正如我所说，我不是专家，我不确定这是否总是那么明确

kubino 于 2017-07-18

@kubino无需成为专家。您知道世界上到处都是自封为专家的人，因此最好不要声称自己是专家，否则可能最终会成为一个one

无论如何，我还没有时间完全阅读该RFC，但我认为它属于label = "Interoperability"部分。也就是说，对于这些情况，我们应该添加optimization部分。就是说，让我们继续对该PR进行讨论，我认为您应该在那里提出建议，并看看@jhabdas对这一

BYK 于 2017-07-18

👍1

@kubino我已经更新了RFC描述，使其更易于使用。

RFC是一项建议，旨在通过引入一个小的（看似不相关的）功能来尝试解决可能会弹出的许多相关用例，这些功能在创造性地使用时旨在帮助满足您提出的需求，同时为纱线已经为社区带来的巨大成就增添了额外的收益。

乐于讨论并利用您的见识进一步完善RFC，因为据我了解，在编码方面，更有经验可能会成为资产的责任，甚至更多。

ghost 于 2017-07-19

👍4

@BYK我知道您的意思；）当然，我需要与你们两个@jhabdas达成

kubino 于 2017-07-20

如果它是可选的“给定目标操作系统”，那么它甚至不应处于WARN级别。作者说：“如果MacOS然后使用FSEvents，否则不使用。” 因此，如果要在Mac以外的其他操作系统上进行安装，则为什么要发出警告？它更像是信息/调试。

robertjchristian 于 2017-07-26

👍2

@robertjchristian我认为这有两个方面：

fsevents本身没有这样的MacOS上这样的OS安装它应该尝试打印警告或错误的工作之外。某些使用fsevents软件包可能普遍（不正确地）依赖于其API，而不知道它们仅适用于macOS，并且在此过程中会破坏其他OS。
如果fsevents是仅在macOS上需要的某些软件包，则这些软件包应能够将fsevents标记为不安装在macOS之外。如果无法在macOS上安装fsevents ，则会导致失败，但在其他OS上甚至都不会尝试安装。

核心问题是将fsevents视为可选依赖项是不正确的方法。缺少的功能是可以在macOS上将fsevents标记为必需，而在其他OS-es上将其标记为完全排除，而不仅仅是可选。

mgol 于 2017-07-26

👍16

是的，这在原始线程中已被多次解释，似乎没有人在听：

https://github.com/npm/npm/issues/11632#issuecomment -238217690

解决方案是增加对特定于平台的依赖项的支持。

https://github.com/npm/npm/issues/11632#issuecomment -257214969

“正确”的解决方案是使用某种条件依赖的方法-一种程序包表示不应将其一个或多个依赖安装在某些平台上的方式。这与将自己描述为特定于平台的程序包不同-程序包不知道它是否为可选程序，因此它只能说“如果将我安装在错误的平台上，那就是错误”。

https://github.com/npm/npm/issues/11632#issuecomment -300804918

这是npm可以做的：
将可选依赖项和不受支持的消息从WARN更改为INFO（大多数人想要的）。
实施平台特定的依赖关系（适当的解决方案）

因此，与其隐藏警告，不如通过实现条件依赖来适当地解决它。但这需要更改package.json规范。我想象这样的事情：

  "conditionalDependencies": {
    {
      "condition": { "platform": "darwin" }, // 'darwin', 'freebsd', 'linux', 'sunos' or 'win32'
      "packages": { "fsevents": "^1.0.0" }
    }
  },

对于fsevents作者，另一种选择是：

使它在没有任何警告的非OSX平台上不失败，只是不支持有关平台的INFO消息

但这与在npm级别隐藏警告没有太大区别。

Vanuan 于 2017-07-27

👍15

还是没有答案？那个警告太烦人了。

IAMtheIAM 于 2018-07-21

👍8

在这一点上，即使我讨厌操作系统，我还是想买Mac只是为了不再看到它四年了。

derekbtw 于 2019-01-27

😄7

在这一点上，即使我讨厌操作系统，我还是想买Mac只是为了不再看到它四年了。

如果您是专业开发软件，我不建议您进行更好的投资。

ghost 于 2019-02-02

👎5 😄3

如果您不要求用户做任何事情来纠正它，为什么还要显示警告？

每个人都在坚持警告，请花点时间思考。如果用户无法采取任何措施来纠正此警告，为什么我们要显示它？

这就像您的伴侣告诉您他们饿了，您就像自己做饭，他们不会做，您不会做饭，但是不断烦扰您，我饿了。每次您打招呼（npm install / yarn）时，他们都会说我饿（WARN WARN WARN）。对我来说似乎毫无意义。

FlyRocketDrones 于 2019-02-14

❤2 👍1

在这一点上，我很想仅出于看不到此的目的而购买Mac

您是说在Mac上看不到吗？
好吧，除非您使用docker，否则您不会：

MacbookPro $ docker run -ti --rm node yarn add [email protected]
yarn add v1.13.0
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.

Vanuan 于 2019-02-15

我认为您最好用运气分叉chokidar并从中删除fsevents 。
最近的节点有了OS X本机fs.watch支持，因此有了很大的改进。

当然，您还必须根据chokidar分叉数十个软件包

Vanuan 于 2019-02-15

尝试在此处抱怨更改：
https://github.com/paulmillr/chokidar/issues

Vanuan 于 2019-02-15

我认为您最好用运气分叉chokidar并从中删除fsevents 。
最近的节点有了OS X本机fs.watch支持，因此有了很大的改进。

听起来我们毕竟在同一个页面上。 xD

ghost 于 2019-02-15

是的，我想等到chokidar放弃对节点10的支持时，这是唯一的选择，此时它将变得毫无用处，并且其他项目开始删除它。

Vanuan 于 2019-02-15

@Vanuan最近对fs.watch的node.js支持仍然很

如果您要抱怨安装警告，也许要向“弃用”软件包的维护者抱怨。真是令人讨厌。过去没有发生过这种情况。与此相比，Fsevents的问题要少得多。

paulmillr 于 2019-02-17

👎6

这是永远不会解决的吗？

tobiasfeil 于 2020-07-16

👍3

Yarn: 不要警告不兼容的可选依赖项

最有用的评论

所有57条评论

相关问题