Yarn: 互換性のないオプションの依存関係について警告しないでください

警告の適切な使用法のように思えます。

警告を表示しているものを単に非表示にするのではなく、修正する方がよいのではないでしょうか。

@wtgtybhertgeghgtwtg

「修正」とはどういう意味ですか？ https://github.com/npm/npm/issues/11632で説明されているように、すべてが意図したとおりに機能しています。 いくつかのパッケージは依存fsevents （それが優れた体験を提供していますので）特にMacOSの上ではなく、Windowsの/ Linux上の他の動作にフォールバックします。 fseventsがWindowsと互換性がないという事実は、ユーザーに明らかにされるべきではありません。これは、依存関係のプラットフォーム固有の実装の詳細にすぎません。 そこにはユーザーにとって実用的なものは何もありません（そして心配する必要はありません）。

依存関係を要求し、特定のOSにバイナリを追加することは、それがどのように機能するかではないはずです。
この問題をポップアップさせる他のパッケージがあると確信していますが、 fseventsが最も優勢なパッケージであり、 babel 、 webpack 、 create-react-app問題が発生します。 saneとjestを確信しています。 1つのパッケージの欠点があるため、パッケージマネージャーの動作を変更するよりも、より優れたファイル監視ソリューションを見つける方が生産的だと思います。

fsevents （またはfsevents自体）を使用するパッケージで何ができるかについて別の提案がある場合は、それを聞きたいです！ ただし、OS固有のパッケージを使用することについて「間違った」ことは何もないと思います。 それは実際の問題を解決し、いくつかの問題はプラットフォーム固有です。

意見が分かれているようです。
実行不可能なことについての警告は迷惑かもしれないと思います。
一方、「このモジュールはNode.js <4では機能しません」などの同様の警告は、非常に便利です。
警告を無効にするために人々がオンにできる設定はありますか？

@gaearonはこれがオープンソースのリポジトリであるとすると、ログレベルで抑制するCLIフラグを追加するPRはどうでしょうか。 それが優れたコンピューターであるか、同じことのほとんどを実行できる35ドルのRPiであるかにかかわらず、参照しているパッケージのダウンストリームの問題について紙に書くのは非常に間違っています。

@jhabdas

ログレベルで抑制するCLIフラグを追加するPRはどうですか

PRを送信したかったのですが、

それが優れたコンピューターであるか、同じことのほとんどを実行できる35ドルのRPiであるかにかかわらず、参照しているパッケージのダウンストリームの問題について紙に書くのは非常に間違っています。

このコメントがわかりません。 私は「下流の問題について紙に書く」ことを提案していません。 fseventsは何も悪いことをしていません。 macOSでのみ有用であり、他のシステムには存在しないことを表現したいと思います。 webpackような他のパッケージは、macOSではfseventsを使用したいが、他のシステムではスキップしたいことを表現したいと考えています。 そして、これはまさにyarnとnpmの両方が行っていることです。

npmとyarnの両方が、怖いように見えても実際には問題を示していないメッセージを出力することをます。 しかし、すべてが意図したとおりに機能するため、ユーザーが心配する理由はありません。 だから私のポイントは、何も問題がないときにユーザーを怖がらせるのをやめたほうがいいということです。

よくわからない場合は申し訳ありません。 私は今、これが私が予想したよりも物議を醸しているのを見ることができます。 それではこれをしないようにしましょう。 私はこの丘で死ぬつもりはありません。 😛

一方、「このモジュールはNode.js <4では機能しません」などの同様の警告は、非常に便利です。

...しかし、それは実用的です–Node.jsのバージョンをアップグレードできます。

...しかし、それは実用的です–Node.jsのバージョンをアップグレードできます。

OSの制限も実行可能である可能性があります。
Mac以外のIOツールをインストールするたびに同じ警告を表示する価値があるかどうかが問題だと思います。依存関係がオプションの場合、Windowsユーザーに表示しない機会を与えるべきだと思います。

再開します。もっと議論する価値があるようです。

おそらくこれを「情報」ログレベルにダウングレードすることができます（そしてnpmのようなログレベルの概念を導入することができます）。

@ gearon2つの無料のテストケースを提供して

@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に同意し慣れておらず、npmの使用からYarnに移行したため、警告が

私の意見では、これらの警告はわかりやすい情報になるか、まったく表示されるべきではないと思います。

ただし、安全でない依存関係を使用すると、警告が表示されます。

なぜ私たちは_怖い_について話しているのですか。 これはソフトウェア開発であり、幼稚園ではありません。

@wtgtybhertgeghgtwtg私をスローするのは、警告が_me_に更新できないものを更新するように要求することです。 この場合、私は安全でない依存関係を使用しているわけではありませんが（Globはそうだと思います）、私はあなたの主張を理解し、警告であるべきだと同意します。 しかし、私はそれがより有益であると言うことができると思います。 「[dependency_A]は古い[dependency_B]を使用しています」のような単純なもの— a） _my_のせいではなく、エラーは私の側にない、 b）どこで確認するのか、すぐにわかります。この問題は解決されました。 この種の情報は、ユーザーが自分の側で何が悪いのかを理解しようとするうさぎの穴を降りるのを防ぐことができます。

最初にメッセージを改善し、PRを送信することをお勧めします

午後02時08分に2017年7月7日、ダニエル・ブレイクの[email protected]は書きました：

@wtgtybhertgeghgtwtghttps ：//github.com/wtgtybhertgeghgtwtg何がスローされ
私は、警告が私が更新できない何かを更新するようにているということです。
この場合、私は安全でない依存関係を使用しているわけではありませんが（I
Globはそうだと思います）、私はあなたの主張を理解し、それが警告であるべきだと同意します。 しかし、私
より有益であると言うことができると思います。 と同じくらい簡単なもの
「[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
。

私をスローするのは、警告が私に更新できないものを更新するように要求することです。

依存関係を使用している場合は、それとそれが取り込むすべてのものを確実に所有し、それに付随するものをすべてフォークして改善することができます。 気になる場合は、使用する価値がない可能性があります。

私はそれを主張しますが

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] ...

あなたが知る必要があることをあなたに伝えます、私はそれがそれをもう少しよく要約する方法で表現されることができることに同意します。

この問題を特定の1つのケースに焦点を当てておくことができますか？ 私はこれがすべての可能な警告についての自転車小屋に変わることを望んでいません。

推移的な依存関係であっても、原則として問題の「修正」が不可能であるという特定の警告を報告しました。 すべてが意図したとおりに機能します。

この問題で説明されている他のケースは、一時的な依存関係によって報告および修正する必要がある正当な問題を示しています。 これは私が説明した問題と似ているとは思いません。 それらについて強く感じている場合は、新しい問題を提出してください。

私はこれがすべての可能な警告についての自転車小屋に変わることを望んでいません。

それが関連しているなら、会話はおそらくここに行くべきです。 未解決の問題の数に注意してください。これは拡張リクエストであり、バグではありません。

いいですね。 退会しますが、この議論が今後も集中していくことを願っています。 参加していただきありがとうございます！

メンテナ、これを閉じてください。 フォローする人は誰もいません。

2つの無料のテストケースを提供していただけますか？

開発中に適切な機能セットに目を光らせていれば、yarnでできる素晴らしいことがたくさんあります。

未解決の問題の数に注意してください。これは拡張リクエストであり、バグではありません。

メンテナ、これを閉じてください。

@jhabdas 、この問題により多くの時間をいただき、ただし、これを繰り返し続ける必要はありません。 これはあまり友好的な行動ではありません。

申し訳ありませんが、すでに述べたように、この問題に時間を割くことはできません。 私は、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 ReactAppがWindowsと互換性がないかのように表示されます。 これは彼らの持ち帰りです。 すべてが後で機能するのは素晴らしいことですが、何かが壊れた場合、これらの警告のおかげで機能しないはずだと考えてしまうため、常に問題を報告するとは限りません。 私はこの提案によってこの印象と戦おうとしています。

なぜ怖い話をしているのですか。 これはソフトウェア開発であり、幼稚園ではありません。

幼稚園でしか怖くないという思いは戸惑います。 人々が一生怖がっていることがたくさんあります。 これには、不安などの精神状態とその他の恐れ（たとえば、仕事が十分に上手ではないことへの恐れ）の両方が含まれます。

JavaScriptツールとは無関係に見えるかもしれませんが、実際にはそうではありません。 ここには2つの別々の問題があります。

1. 不明確で実行不可能な警告は人々を不安にさせます。 彼らは彼らに彼らのツールをあまり信用させず、彼らがしなかったとしても彼らが何か間違ったことをしたかどうか彼らを混乱させます。 これは、キャシー・シエラによって非常によく説明されている認知の消耗に貢献しています。

2. 行動不可能な警告音は、人々に警告の死角を生じさせます。 人々はそれらを無視することを学びます。 実行不可能な警告はすべて、このコストの原因になります。 ヤーンだけでなく、さまざまなツールで何度も発生するのを見てきました。 それは「オオカミを泣いた少年」のシナリオです。 その結果、重要でないものの海で重要な警告を見逃したため、将来、人々は問題を診断できず、自分とメンテナの時間を費やすことができなくなります。

これにより、対処する価値があると思う理由が明らかになることを願っています。 しかし、あなたはこの提案を打ち切ることに非常に熱心であるように思われるので、私はこの議論にこれ以上参加しません、そして私はあなたとそれを議論することにもっと個人的なエネルギーを投資するつもりはありません。

これは私が@gaearonを引き出したいと思っていた情報の深さです。 学習者への共感が輝いているようで、それは称賛に値するので、説明に時間を割いていただきありがとうございます。

自分で釣りをすることを学習者に教えることが重要だと思います。 そして時にはそれは彼らを彼らの恐れから保護するのではなく、代わりに彼らに恐れに正面から向き合うように促すことを意味します。

fsevents警告の場合、オプションの依存関係であっても、学習者は警告を観察し、それを理解しようとするように促されるべきです。 そうでなければ、彼らは成長しません。

たとえば、Stack Overflowをすばやく検索すると、説明されている警告メッセージを処理するための次の解決策が表示されます： https ：

認知的オーバーヘッドが懸念される場合は、個人がシングルページアプリを作成するための別のツールを探すか、Webの基礎を習得するの

@ glen-84意見を共有したいですか、それとも親指を立てるだけですか？

承知しました。

• 実行不可能で問題を引き起こさないものについて警告を表示すると、次のようになります。
  
  
  
  • 開発者が最初にそれが起こっている理由を見つけなければならず、次にそれを毎回無視しなければならないことによる無駄な時間（そして警告を無視することは悪いことです）
  
  
  • Yarn / npm開発者による無駄な時間、なぜそれが起こるのかを説明しなければならない
  
  
  • ダウンストリームツーリングエラー
  
  
  • 等
  
  
• npmの問題からの投票を組み合わせると、150人近くのユーザーが同意します。
• 理論的には、npm開発者は受け入れて

IMOはこの議論に価値をもたらさないため、私はあなたのコメントのうち2つに反対票を投じました。

私は、実行不可能な警告は役に立たず、不必要に怖い/騒々しい/可能性があることに同意します。 提案@bestanderとして@dmbdesignpdxさんの提案で行こうか？

PRの歓迎。

開発者が最初にそれが起こっている理由を見つけなければならず、次にそれを毎回無視しなければならないことによる無駄な時間（そして警告を無視することは悪いことです）

あなたはそれを無視しません。 あなたはそれが起こっている理由を学び、行動を起こします。 これにより、関連するNPMの問題で@Vanuanが示唆している場合があります。

Yarn / npm開発者による無駄な時間、なぜそれが起こるのかを説明しなければならない

個々のリポジトリまたはパッケージマネージャーからの問題に対処することは、Yarnの責任ではありません。 そして、NPMだけがパッケージャーではありません。 そして個人的には、Yarnが成長してComposerに取って代わり、バウアーが赤いニシンに気を取られるのではなく、コミュニティを去ったばかりの空白を埋めることを望んでいます。

npmの問題からの投票を組み合わせると、150人近くのユーザーが同意します。

それは論争の広告人口です。 委員会による設計は誰にとってもうまくいきません。

話し合いがあったのでcat-discussonラベルを削除しました。今、実行可能なことがあります。どのパッケージが他の非推奨パッケージに依存しているかを示すことで、警告をより便利にします。

@jhabdas 「学習」と「行動」の部分に同意すると思います。 私たちがあまり同意していないように見える部分は、私たちがそれをどのように行うか、そしてそれがyarnの義務であるかどうかです。 今のところ、ユーザーにとって役立つ糸が多いほど良いと思います。 とはいえ、より重要な修正や更新からリソースを奪うためにこれを優先するつもりはないので、PRのためにコミュニティに任せます。

この問題についてもっと話し合いたい人がいたら、Discordに移しましょう。 そこに直接pingして、注意を引くことができます。 💓

あなたはそれが起こっている理由を学び、行動を起こします

どのような行動を取るべきですか？

個々のリポジトリまたはパッケージマネージャーからの問題に対処することは、Yarnの責任ではありません。

この問題に関して繰り返し報告される問題を目にするのはYarnとnpmの開発者であり、新機能やバグ修正に取り組む代わりに、不必要な問題の切り分けに時間を費やす必要があります。

それは論争の広告人口です。 委員会による設計は誰にとってもうまくいきません。

現在のところこれですべてです。これらの変更に同意できない場合は、この問題への反対票を投じることで、メンテナの意思決定に役立ちます。

わかりました@ glen-84は、元の問題がサブ依存関係と有益なメッセージに関するものではなく、特定のプラットフォームにインストールできないパッケージに関する警告ではないことを親切に思い出させました。

したがって、この特定のチケットのアクションは、付加価値がないため、警告から情報またはデバッグに単純に下げることです。 異議はありますか？ 他の部分を＃3869に移動しました。

@gaearonこの問題を解決するために、

@jhabdas私はすでにPRで答えました。 これは私の哲学https://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565ですが、パッケージの互換性または特にその部分にいくつかのテストが必要だと思われる場合は、プルリクエストを開き、事前に感謝します:)

私はあなたの良い判断を信頼しますが、小枝を投げることができる限り、私はSOを信頼します。 しかし、それは大丈夫です。 他の人の利益のためにメッセージを送信して、1行のコード変更でこのスレッド全体を回避する方法を確認したいと思いました。 時には行動は言葉よりも雄弁です。 乾杯。

@jhabdasの貢献に感謝しますが、私たちの行動規範、特に次の項目を思い出させていただきたいと思います。

• 歓迎的で包括的な言葉を使う
• 異なる視点や経験を尊重する
• 他のコミュニティメンバーに共感を示す

心からお詫び申し上げます。 私は行動規範を見直し、良いコミュニティ市民になるために努力します。 正しい方向に向けてくれてありがとう、@ BYK。

これを修正していただきありがとうございます。 😍🙇

これはNPMで最も多く投票された問題であり、実際の問題を引き起こしましたが、1。5年間対処しなかった後、ボットは古すぎるために自動的に閉じました。

そのようなプロジェクト管理が、私がYarnに切り替えた理由の1つです。

修正がいかに簡単であったかを見ると、これにどれだけの時間と労力が浪費されたかが苦痛です。 😢

ありがとう！

こんにちは、これに関するすべての努力に感謝します。 stderrorではなくstdoutに表示される方がはるかに優れています;）。 それでもなお、情報レベルでさえ、ここにたくさんの人々を連れてくるでしょう。 そして、関連する問題を1時間読んだ後に得られる唯一の出力は、今のところ（babelを使用しない）それと一緒に暮らす必要があることと、オプションの依存関係を介してプラットフォーム固有の最適化を行うことは可能ですが、コストがかかることですパッケージマネージャーのユーザーへの警告。 私はこれをデバッグレベルでのみ出力する側にいます。

@kubinoそれはいくつかの素晴らしいフィードバックです、ありがとう！ info移動しても、完全に修正されるわけではないことを認識しています。 そのために、 @ jhabdasは実際にそれをさらに良く、一般的にするために時間を費やし、RFCを

@BYKはまだこれに興味を持ってくれてありがとう。 私は専門家になるにはほど遠いので、間違っているかもしれません。 タイトルが「非推奨のサブパッケージ警告をより有益にする」であるRFCを私に指摘しました。 DEPRECATED警告をユーザーに配信することは、デフォルトでは正しいと思います（ただし、特定のパッケージ警告を抑制する方法があるとよいでしょう）。
私の懸念は、いくつかの具体的なプラットフォームの最適化として機能するオプションの依存関係についてでした。それ以外の場合は非常にきれいなヤーン出力を汚染する価値はほとんどありません。 しかし、私が言ったように、私は専門家ではなく、これが常に決定するのがそれほど明確であるかどうかはわかりません

@kubinoは専門家である必要はありません。 あなたは世界が自称専門家でいっぱいであることを知っているので、専門家ではないと主張する方が良いでしょう、そしてあなたは1人になるかもしれません😀

とにかく、私はまだそのRFCを完全に読む時間がありませんでしたが、それはlabel = "Interoperability"セクションに該当すると思います。 そうは言っても、これらの場合にはoptimizationセクションを追加する必要があるかもしれません。 そうは言っても、そのPRについての議論を続けましょう。そこでこの提案をして、 @ jhabdasがそれについてどう思うかを見て

@kubino RFCの説明を

RFCは、小さな（一見無関係に見える）機能を導入することでポップアップする可能性のあるいくつかの関連するユースケースに対処するための提案です。創造的に使用すると、あなたが提起したようなニーズを満たすのに役立ちます。 Yarnがコミュニティのためにすでに達成した素晴らしい仕事に追加の利点を追加します。

RFCをさらに強化するために、あなたの洞察について話し合い、使用してください。経験を積むことは、コーディングに関しては資産になる可能性があるのと同じくらい、またはそれ以上の責任になる可能性があることを学びました。

@BYK私はあなたがどこを指しているか知っています;）確かに私はあなたの両方に同意する必要があります@jhabdas 、一般的な解決策はこの議論からの唯一の方法です。 メッセージの分類は、他のすべてを可能にする最初のステップです...関連するRFCでの議論を続けましょう。 ありがとう！

オプションの「ターゲットOSが与えられた」場合は、WARNレベルであってはなりません。 著者は、「MacOSの場合はFSEventsを使用し、そうでない場合は使用しない」と述べています。 では、Mac以外のOSにインストールする場合、なぜ警告するのでしょうか。 それはinfo / debugのようなものです。

@robertjchristianこれには2つの側面があると思います。

1. fsevents自体、そのようなOSにインストールしようとする試みは、警告やエラーを印刷する必要がありますので、MacOSのの作業外側をしません。 fseventsを使用する一部のパッケージは、macOSのみであり、プロセス内の他のOSで動作していることを知らずに、そのAPIに普遍的に（誤って）依存する場合があります。
2. fseventsがmacOSでのみ必要な一部のパッケージ用である場合、それらのパッケージはfseventsをmacOSの外部にインストールしないものとしてマークできるはずです。 macOSにfseventsをインストールしないと失敗しますが、他のOSではインストールしようとさえしません。

中心的な問題は、 fseventsをオプションの依存関係として扱うことは誤ったアプローチであるということです。 不足しているのは、macOSでは必須としてfseventsをマークし、他のOSではオプションとしてだけでなく完全に除外する機能です。

ええ、それは元のスレッドで何度か説明されていましたが、誰も聞いていなかったようです：

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

解決策は、プラットフォーム固有の依存関係のサポートを追加することです。

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

「正しい」解決策は、条件付き依存関係のいくつかの方法を用意することです。パッケージが、その依存関係の1つ以上を一部のプラットフォームにインストールしてはならないことを示す方法です。 これは、プラットフォーム固有としてそれ自体を説明するパッケージと同じではありません-パッケージはそれがオプションであるかどうかを知らないので、「間違ったプラットフォームにインストールした場合、それはエラーです」と言うことができます。

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

npmでできることは次のとおりです。

1. オプションの依存関係とサポートされていないメッセージをWARNからINFO（ほとんどの人が望むもの）に変更します。
2. プラットフォーム固有の依存関係を実装する（適切なソリューション）

したがって、警告を非表示にする代わりに、条件付き依存関係を実装することで警告を適切に修正する必要があります。 ただし、package.jsonの仕様を変更する必要があります。 私はこのようなものを想像します：

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

もう1つの方法は、fseventsの作成者向けです。

警告なしにOSX以外のプラットフォームで失敗しないようにします。プラットフォームに関するINFOメッセージのみがサポートされていません

しかし、それはnpmレベルで警告を非表示にすることと大差ありません。

それでも答えはありませんか？ その警告はとても迷惑です。

この時点で、私はオペレーティングシステムを嫌っていても、これをさらに4年間見ないという唯一の目的のために、Macを購入したいと思っています👎

この時点で、私はオペレーティングシステムを嫌っていても、これをさらに4年間見ないという唯一の目的のために、Macを購入したいと思っています👎

あなたが専門的にソフトウェアを開発しているなら、私はより良い投資を勧めることができませんでした。

ユーザーがそれを修正するために何かをする必要がないのに、なぜ警告を表示するのですか？

警告を守ることを主張する皆さん、少し考えてみてください。 ユーザーがこの警告を修正するために何もできない場合、なぜそれを表示しているのですか？

それはあなたのパートナーが彼らが空腹だと言っているようなものです、あなたはあなた自身のために料理をするようなものです、彼らはそれをしません、あなたは彼らが食べない料理をします、しかしあなたを悩ませ続けます、私は空腹です。 こんにちは（npmインストール/ yarn）と言うたびに、彼らは私がお腹が空いていると言います（WARN WARN WARN）..私には無意味に思えます。

この時点で、私はこれを見ないという唯一の目的のために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.

チョキダーをフォークしてそこからfseventsを削除したほうが幸運だと思います。
最近のノードでは、OS Xでのネイティブfs.watchサポートが大幅に改善されています。

もちろん、chokidarによっては数十のパッケージをフォークする必要があります

ここで変更について文句を言ってみてください：
https://github.com/paulmillr/chokidar/issues

チョキダーをフォークしてそこからfseventsを削除したほうが幸運だと思います。
最近のノードでは、OS Xでのネイティブfs.watchサポートが大幅に改善されています。

結局、同じページにいるように聞こえます。 xD

ええ、chokidarがノード10のサポートを終了するまで待つ唯一の選択肢だと思います。その時点でノード10は役に立たなくなり、他のプロジェクトがそれを削除し始めます。

@Vanuan最近の

インストールの警告について不平を言う場合は、パッケージを「非推奨」にするメンテナに不平を言うかもしれません。 それは本当に迷惑です。 これは過去には起こりませんでした。 Fseventsはこれに比べてはるかに問題が少ないです。

これは決して修正されることはありませんか？