Yarn: Warnen Sie nicht vor inkompatiblen optionalen Abhängigkeiten

Erstellt am 27. Juni 2017  ·  57Kommentare  ·  Quelle: yarnpkg/yarn

Derzeit stimmt das Garnverhalten mit npm überein, da es vor optionalen Abhängigkeiten warnt, die nicht kompatibel sind (und daher übersprungen werden). fsevents unter Windows ist ein gutes Beispiel dafür.

Da die Warnung fast nie umsetzbar ist und für Anfänger etwas beängstigend erscheint, schlage ich vor, dass wir die Protokollstufe herabstufen. Ich bin mir nicht sicher, ob Yarn überhaupt ein Konzept für Protokollstufen hat, aber ich möchte diese Warnung nur sehen, wenn ich Yarn selbst speziell debugge.

Das entsprechende npm-Problem wird umfassend unterstützt (obwohl es automatisch geschlossen wurde): https://github.com/npm/npm/issues/11632

help wanted triaged

Hilfreichster Kommentar

@wtgtybhertgeghgtwtg

Was meinst du mit "reparieren"? Wie unter https://github.com/npm/npm/issues/11632 erläutert, funktioniert alles wie vorgesehen. Einige Pakete hängen von fsevents speziell von macOS (weil es eine überlegene Erfahrung bietet), greifen jedoch auf ein anderes Verhalten unter Windows / Linux zurück. Die Tatsache, dass fsevents nicht mit Windows kompatibel ist, sollte den Benutzern nicht angezeigt werden: Es handelt sich lediglich um ein plattformspezifisches Implementierungsdetail einer Abhängigkeit. Es gibt dort nichts umsetzbares für Benutzer (und nichts, worüber man sich beunruhigen könnte).

Alle 57 Kommentare

Scheint mir eine angemessene Verwendung von warn zu sein.

Wäre es nicht besser, das Ding zu reparieren, das die Warnung gibt, als es nur zu verstecken?

@wtgtybhertgeghgtwtg

Was meinst du mit "reparieren"? Wie unter https://github.com/npm/npm/issues/11632 erläutert, funktioniert alles wie vorgesehen. Einige Pakete hängen von fsevents speziell von macOS (weil es eine überlegene Erfahrung bietet), greifen jedoch auf ein anderes Verhalten unter Windows / Linux zurück. Die Tatsache, dass fsevents nicht mit Windows kompatibel ist, sollte den Benutzern nicht angezeigt werden: Es handelt sich lediglich um ein plattformspezifisches Implementierungsdetail einer Abhängigkeit. Es gibt dort nichts umsetzbares für Benutzer (und nichts, worüber man sich beunruhigen könnte).

Ich würde sagen, dass das Erfordernis einer Abhängigkeit und das Hinzufügen von Binärdateien für ein bestimmtes Betriebssystem nicht so funktionieren sollte.
Ich bin mir sicher, dass es andere Pakete gibt, die dieses Problem auftauchen lassen, aber fsevents ist das am meisten vorherrschende Problem, da Probleme in babel , webpack , Ihrem create-react-app , und ich bin mir sicher, dass sehr bald sane und jest . Ich denke, dass es produktiver wäre, eine bessere Lösung zum Beobachten von Dateien zu finden, anstatt das Verhalten eines Paketmanagers aufgrund der Mängel eines Pakets zu ändern.

Wenn Sie einen alternativen Vorschlag haben, welche Pakete mit fsevents (oder fsevents selbst) funktionieren könnten, würde ich das gerne hören! Ich glaube nicht, dass irgendetwas "falsch" ist, wenn man ein Paket hat, das für das Betriebssystem spezifisch ist. Es löst ein echtes Problem und einige Probleme sind plattformspezifisch.

Sieht aus wie Meinungen geteilt sind.
Ich nehme an, eine Warnung vor einer nicht umsetzbaren Sache könnte ärgerlich sein.
Andererseits sind ähnliche Warnungen, z. B. "Dieses Modul funktioniert nicht auf Node.js <4", sehr nützlich.
Gibt es Einstellungen, die aktiviert werden können, um Warnungen zu deaktivieren?

@gaearon Da dies ein Open-Source-Repo ist, wie wäre es mit einem PR, der ein CLI-Flag hinzufügt, das nach Protokollstufe unterdrückt werden soll. Es wäre sehr falsch, ein Downstream-Problem in den Paketen, auf die Sie verweisen, zu dokumentieren, ob es sich um einen überlegenen Computer oder nur um ein RPi von 35 US-Dollar handelt, das die meisten der gleichen Aufgaben ausführen kann.

@ Jhabdas

Wie wäre es mit einem PR, der ein CLI-Flag hinzufügt, das nach Protokollstufe unterdrückt werden soll?

Ich hätte gerne eine PR gesendet , aber wie

Es wäre sehr falsch, ein Downstream-Problem in den Paketen, auf die Sie verweisen, zu dokumentieren, ob es sich um einen überlegenen Computer oder nur um ein RPi von 35 US-Dollar handelt, das die meisten der gleichen Aufgaben ausführen kann.

Ich verstehe diesen Kommentar nicht. Ich schlage nicht vor, „ein nachgelagertes Thema zu überarbeiten“. fsevents macht nichts falsch. Es möchte zum Ausdruck bringen, dass es nur unter macOS nützlich ist, aber auf anderen Systemen nicht existiert. Andere Pakete, wie webpack , möchten ausdrücken, dass sie fsevents unter macOS verwenden möchten, möchten es aber auf anderen Systemen überspringen. Und genau das tun sowohl Garn als auch Npm.

Alles funktioniert bereits wie beabsichtigt, außer dass sowohl npm als auch Garn eine Nachricht drucken, die beängstigend aussieht, aber eigentlich kein Problem anzeigt . Es gibt jedoch keinen Grund für den Benutzer, sich Sorgen zu machen, da alles wie beabsichtigt funktioniert. Mein Punkt ist also, dass es schön wäre, die Benutzer nicht mehr zu erschrecken, wenn nichts falsch ist.

Entschuldigung, wenn ich nicht sehr klar bin. Ich kann jetzt sehen, dass dies kontroverser ist als ich erwartet hatte. Lass uns das dann nicht machen. Ich werde auf diesem Hügel nicht sterben. 😛

Andererseits sind ähnliche Warnungen, z. B. "Dieses Modul funktioniert nicht auf Node.js <4", sehr nützlich.

... aber das ist umsetzbar - Sie können Ihre Version von Node.js aktualisieren.

... aber das ist umsetzbar - Sie können Ihre Version von Node.js aktualisieren.

Eine Betriebssystembeschränkung kann ebenfalls umsetzbar sein.
Ich nehme an, die Frage ist, ob es sich lohnt, bei jeder Installation eines E / A-Tools, das nicht auf einem Mac installiert ist, dieselbe Warnung anzuzeigen. Ich denke, wir sollten Windows-Benutzern die Möglichkeit geben, sie nicht anzuzeigen, wenn die Abhängigkeiten optional sind.

Ich werde wieder öffnen, es scheint sich zu lohnen, mehr zu diskutieren.

Wir könnten dies wahrscheinlich auf eine "Info" -Protokollebene herabstufen (und ein Konzept für Protokollebenen wie npm einführen).

@gearon Könnten Sie bitte zwei kostenlose Testfälle bereitstellen? Ich las die Details und hörte den Vorschlag. Aber ich möchte persönlich das, was Sie für Anfänger als beängstigend empfinden, für etwas aufnehmen, das "fast nie umsetzbar" ist. Sie haben oben Webpack erwähnt. Für mich ist Webpack selbst beängstigend und ich benutze es daher nicht. Es gibt viele großartige Dinge, die mit Garn gemacht werden können, wenn es während der Entwicklung die richtigen Funktionen im Auge behält. Ist dies wirklich ein Vorschlag, der Ihrer Meinung nach zur Erreichung dieser Ziele beiträgt, oder klettern Sie auf den Hügel eines anderen?

Ich habe eine ähnliche Situation wie von @gaearon beschrieben : Ich

Wenn ich yarn upgrade starte, bekomme ich dies am Anfang:

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

Wenn ich mir jedoch die folgende Liste ansehe, sind diese Abhängigkeiten auf dem neuesten Stand.

Ich stimme @gaearon zu , eine Warnung zu sehen ist ein bisschen beängstigend, besonders für mich, da ich relativ neu in der Verwendung von Node bin und von npm auf Yarn umgestiegen bin. Aber es ist auch ein bisschen irreführend, eine Warnmeldung zu sehen, da dies impliziert, dass es etwas ist, das ich beheben kann.

Meiner Meinung nach sollten diese Warnungen entweder zu freundlichen Infos werden oder überhaupt nicht angezeigt werden.

Die Verwendung unsicherer Abhängigkeiten sollte jedoch eine Warnung geben.

Warum reden wir über beängstigend. Dies ist Softwareentwicklung, kein Kindergarten.

@wtgtybhertgeghgtwtg Was mich a) es nicht mein Fehler ist, der Fehler nicht auf meiner Seite liegt und b) wohin ich gehen soll, um zu sehen, ob Das Problem wurde behoben. Diese Art von Informationen kann Benutzer davon abhalten, in den Kaninchenbau zu gehen und herauszufinden, was an ihrem Ende falsch ist.

Gute Idee, um die Nachricht zuerst zu verbessern, senden Sie eine PR

Am 7. Juli 2017 um 14:08 schrieb Daniel Blake [email protected] :

@wtgtybhertgeghgtwtg https://github.com/wtgtybhertgeghgtwtg Was wirft
Die Warnung fordert mich auf, etwas zu aktualisieren, das ich nicht aktualisieren kann.
Auch wenn ich in diesem Fall nicht derjenige bin, der die unsichere Abhängigkeit verwendet (I.
denke, Glob ist), ich verstehe Ihren Standpunkt und stimme zu, dass es eine Warnung sein sollte; aber ich
Ich denke, es kann so formuliert werden, dass es informativer ist. Etwas so Einfaches wie
"[dependency_A] verwendet ein veraltetes [dependency_B]" - Ich werde es sofort wissen
die Fledermaus, dass a) es nicht meine Schuld ist, der Fehler nicht an meinem Ende ist, und
b) wohin, um zu sehen, ob das Problem behoben wurde. Diese Art von
Informationen können Benutzer davor bewahren, das Kaninchenloch hinunterzugehen, um es herauszufinden
Was ist los an ihrem Ende.

- -
Sie erhalten dies, weil Sie den Öffnungs- / Schließstatus geändert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/3738#issuecomment-313793331 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/ACBdWI1Ks6bSYH_BStzm_b3-ne3bUMT3ks5sLp5PgaJpZM4OGrsi
.

Was mich wirft ist, dass die Warnung mich auffordert, etwas zu aktualisieren, das ich nicht aktualisieren kann.

Wenn Sie eine Abhängigkeit verwenden, besitzen Sie sie mit Sicherheit und alles, was sie enthält, und haben die Fähigkeit, alles, was damit verbunden ist, zu teilen und zu verbessern. Wenn es Sie stört, lohnt es sich vielleicht nicht, es zu benutzen.

Während ich das argumentieren würde

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

Wenn Sie wissen, was Sie wissen müssen, stimme ich zu, dass es so formuliert werden könnte, dass es etwas besser zusammengefasst wird.

Können wir dieses Problem bitte auf einen bestimmten Fall konzentrieren? Ich möchte nicht, dass daraus ein Bikeshed über alle möglichen Warnungen wird.

Ich habe eine spezielle Warnung gemeldet, bei der das "Beheben" des Problems im Prinzip unmöglich ist, nicht einmal in den transitiven Abhängigkeiten. Alles funktioniert wie vorgesehen.

Andere in diesem Problem beschriebene Fälle weisen legitime Probleme auf, die durch transitive Abhängigkeiten gemeldet und behoben werden müssen. Ich denke nicht, dass dies dem von mir beschriebenen Problem ähnlich ist. Wenn Sie sich stark für sie fühlen, reichen Sie bitte eine neue Ausgabe ein.

Ich möchte nicht, dass daraus ein Bikeshed über alle möglichen Warnungen wird.

Wenn es verwandt ist, sollte das Gespräch wahrscheinlich genau hier stattfinden. Bitte beachten Sie die Anzahl der offenen Probleme und dass dies eine Erweiterungsanforderung und kein Fehler ist.

Klingt gut. Ich werde mich abmelden, aber ich hoffe, dass diese Diskussion auch in Zukunft konzentriert bleibt. Vielen Dank für Ihre Teilnahme!

Betreuer, bitte schließen Sie diese. Es gibt niemanden, dem man folgen kann.

Könnten Sie bitte zwei kostenlose Testfälle bereitstellen?

Es gibt viele großartige Dinge, die mit Garn gemacht werden können, wenn es während der Entwicklung die richtigen Funktionen im Auge behält.

Bitte beachten Sie die Anzahl der offenen Probleme und dass dies eine Erweiterungsanforderung und kein Fehler ist.

Betreuer, bitte schließen Sie diese.

@jhabdas , ich aufzuwenden , und darauf hinzuweisen, dass das Garn-Team genug auf dem Teller hat, aber es besteht keine Notwendigkeit, dies immer wieder zu wiederholen. Dies ist kein sehr freundliches Verhalten.

Ich entschuldige mich, aber wie ich bereits sagte, kann ich diesem Thema nicht wirklich Zeit widmen. Ich vertraue darauf, dass die Garnpfleger bei der Priorisierung die richtigen Entscheidungen treffen. Wenn sie der Meinung sind, dass das Problem eine zu niedrige Priorität hat, werden sie es zu Recht ignorieren oder schließen.

Bitte verzeihen Sie, wenn ich etwas falsch verstehe und Sie an der Pflege dieses Repositorys beteiligt sind. In diesem Fall können Sie dieses Problem gerne schließen.

Aber ich möchte persönlich das, was Sie für Anfänger als beängstigend empfinden, für etwas aufnehmen, das "fast nie umsetzbar" ist.

Wenn Sie create-react-app installieren und dann create-react-app myapp ausführen, wird im Rahmen der Installation eine Warnung ausgegeben:

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.

Die npm-Warnung ist noch beängstigender:

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"})

Glücklicherweise können wir mit npm die Protokollstufe angeben, die Yarn nicht angibt. Leider müssen wir deshalb alle npm-Warnungen ignorieren.

Warum ist diese Warnung ein Problem?

Für einen erfahrenen Benutzer wie Sie ist dies kein Problem. Die Create React App ist für viele Menschen der Einstieg in das React- und npm-Ökosystem. Für manche Menschen ist es ein Einstieg in die Webentwicklung.

Sie wissen nicht, was fsevents ist. Die Nachricht lautet, als ob Create React App nicht mit Windows kompatibel ist. Dies ist ihr Essen zum Mitnehmen. Es ist großartig, wenn alles später funktioniert, aber wenn etwas kaputt geht, melden sie nicht immer ein Problem, weil sie auf die Idee kommen, dass es dank dieser Warnungen nicht funktionieren soll . Ich versuche, diesen Eindruck durch diesen Vorschlag zu bekämpfen.

Warum reden wir über beängstigend. Dies ist Softwareentwicklung, kein Kindergarten.

Die Annahme, dass Menschen nur im Kindergarten Angst bekommen, ist für mich verwirrend. Es gibt viele Dinge, vor denen Menschen im Laufe ihres Lebens Angst haben. Dies schließt sowohl psychische Zustände wie Angstzustände als auch andere Ängste ein (z. B. Angst, dass Sie bei Ihrer Arbeit nicht gut genug sind).

Es scheint nicht mit JavaScript-Tools zu tun zu haben, ist es aber wirklich nicht. Hier gibt es zwei verschiedene Probleme:

  1. Unklare, nicht umsetzbare Warnungen machen den Menschen Angst. Sie lassen sie ihren Werkzeugen weniger vertrauen und verwirren, ob sie etwas falsch gemacht haben, auch wenn sie es nicht getan haben. Dies trägt zu einem kognitiven Abfluss bei, der von Kathy Sierra so gut beschrieben wurde .

  2. Durch nicht aktivierbares Warngeräusch entwickeln Menschen einen toten Winkel für Warnungen. Die Leute lernen, sie zu ignorieren. Jede nicht umsetzbare Warnung trägt zu diesen Kosten bei. Wir haben viele Male mit verschiedenen Werkzeugen gesehen, nicht nur mit Garn. Es ist das Szenario „Der Junge, der den Wolf geweint hat“. Infolgedessen können Menschen in Zukunft Probleme nicht diagnostizieren und ihre Zeit und die der Betreuer verbringen, weil sie eine wichtige Warnung im Meer unwichtiger Probleme verpasst haben.

Ich hoffe, dies hat klargestellt, warum ich denke, dass es sich lohnt, darauf einzugehen. Ich werde jedoch nicht weiter an dieser Diskussion teilnehmen, da Sie anscheinend sehr leidenschaftlich daran interessiert sind, diesen Vorschlag abzuschießen, und ich nicht bereit bin, mehr persönliche Energie in die Diskussion mit Ihnen zu investieren.

Dies ist die Tiefe der Informationen, die ich gehofft hatte, @gaearon herauszuholen. Vielen Dank, dass Sie sich die Zeit genommen haben, dies zu erklären, da Ihr Einfühlungsvermögen für den Lernenden zu strahlen scheint und das lobenswert ist.

Ich finde es wichtig, dass wir den Lernenden beibringen, selbst zu fischen. Und manchmal bedeutet das, sie nicht vor ihren Ängsten zu schützen, sondern sie zu ermutigen, sich direkt der Angst zu stellen.

Im Fall einer fsevents -Warnung sollten Lernende auch als optionale Abhängigkeit aufgefordert werden, die Warnung zu beachten und zu verstehen. Sonst wachsen sie nicht.

Eine schnelle Suche nach Stapelüberlauf bietet beispielsweise die folgende Lösung für die Behandlung der beschriebenen Warnmeldung: https://stackoverflow.com/a/42938398/712334.

Wenn der kognitive Aufwand zu einem Problem wird, würde ich eine Person ermutigen, ein anderes Tool zum Erstellen ihrer einseitigen Apps zu suchen oder ihre Wissensreise an einem Ort zu beginnen, der besser geeignet ist, um die Grundlagen des Webs zu erlernen.

@ glen-84 Möchtest du deine Meinung teilen oder einfach deinen Daumen herumwerfen?

Sicher.

  • Das Anzeigen einer Warnung zu etwas, das nicht umsetzbar ist und keine Probleme verursacht, führt zu:

    • Zeitverschwendung durch Entwickler, die zuerst herausfinden müssen, warum es passiert, und es dann jedes Mal ignorieren müssen (und das Ignorieren von Warnungen ist eine schlechte Sache)

    • Zeitverschwendung durch Yarn / npm-Entwickler, die erklären müssen, warum dies geschieht

    • Nachgelagerte Werkzeugfehler

    • usw.

  • Wenn Sie die Stimmen aus der npm-Ausgabe kombinieren, stimmen fast 150 Benutzer zu.
  • Die npm-Entwickler haben die Änderung theoretisch bereits akzeptiert .

Ich habe zwei Ihrer Kommentare abgelehnt, weil sie meiner Meinung nach dieser Diskussion keinen Wert hinzufügen.

Ich bin damit einverstanden, dass Warnungen, die nicht umsetzbar sind, nicht nützlich sind und auch unnötig beängstigend / laut / sein können.. Gehen wir zu @dmbdesignpdx 'Vorschlag, wie @bestander vorgeschlagen hat?

PR ist willkommen.

Zeitverschwendung durch Entwickler, die zuerst herausfinden müssen, warum es passiert, und es dann jedes Mal ignorieren müssen (und das Ignorieren von Warnungen ist eine schlechte Sache)

Du ignorierst es nicht. Sie lernen, warum es passiert und ergreifen Maßnahmen. Manchmal führt dies zu einem anderen Toolset oder einem Problem im Repo, das die Grundursache behebt, wie von

Zeitverschwendung durch Yarn / npm-Entwickler, die erklären müssen, warum dies geschieht

Es liegt nicht in der Verantwortung von Yarn, Probleme von einzelnen Repositories oder Paketmanagern zu lösen. Und NPM ist nicht der einzige Packager da draußen. Und ich persönlich würde es vorziehen, wenn Yarn wächst, um Composer zu ersetzen und die Lücke zu füllen. Bower hat gerade die Community verlassen, anstatt sich von roten Heringen ablenken zu lassen.

Wenn Sie die Stimmen aus der npm-Ausgabe kombinieren, stimmen fast 150 Benutzer zu.

Das ist argumentum ad populum. Design by Committee funktioniert für niemanden gut.

Das Label cat-discusson seit wir unsere Diskussion hatten, und jetzt haben wir eine umsetzbare Sache zu tun: Machen Sie die Warnung nützlicher, indem Sie angeben, welches Paket von diesem anderen veralteten Paket abhängt.

@jhabdas Ich denke, wir sind uns einig über die Teile "Lernen" und "Handeln". Der Teil, dem wir nicht allzu sehr zustimmen, ist, wie wir es machen und ob es die Pflicht von yarn oder nicht. Im Moment denke ich, je hilfreicher das Garn für seine Benutzer ist, desto besser ist es. Das heißt, ich würde dies nicht hoch priorisieren, um Ressourcen von kritischeren Korrekturen und Updates zu entfernen, daher schieben wir uns für eine PR an die Community.

Wenn jemand mehr über dieses Thema diskutieren möchte, verschieben wir es in Discord. Sie können mich dort direkt anpingen, um meine Aufmerksamkeit zu erregen. 💓

Sie lernen, warum es passiert und ergreifen Maßnahmen

Welche Maßnahmen sollten wir ergreifen?

Es liegt nicht in der Verantwortung von Yarn, Probleme von einzelnen Repositories oder Paketmanagern zu lösen.

Es sind Entwickler von Yarn und npm, die wiederholt gemeldete Probleme in dieser Angelegenheit sehen und Zeit mit unnötiger Problemlösung verbringen müssen, anstatt an neuen Funktionen und Fehlerkorrekturen zu arbeiten.

Das ist argumentum ad populum. Design by Committee funktioniert für niemanden gut.

Es ist alles, was wir derzeit haben, und wenn Sie mit diesen Änderungen nicht einverstanden sind, würde Ihre Ablehnung des Themas den Betreuern bei ihrer Entscheidungsfindung helfen.

Okay @ glen-84 hat mich freundlich daran erinnert, dass es bei dem ursprünglichen Problem nicht um Unterabhängigkeiten und informative Nachrichten ging, sondern einfach nicht um ein Paket, das nicht auf einer bestimmten Plattform installiert werden kann.

Die Aktion für dieses spezielle Ticket besteht nun darin, es einfach von einer Warnung auf Info oder Debug zu senken, da es keinen Mehrwert bietet. Einwände? Der andere Teil wurde auf # 3869 verschoben.

@gaearon Eine einzeilige Codeänderung ohne

@jhabdas Ich habe bereits in der PR geantwortet. Dies ist meine Philosophie https://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565, aber wenn Sie der Meinung sind, dass die Paketkompatibilität oder dieser Teil insbesondere einige Tests erfordert, bitte Öffne eine Pull-Anfrage und danke im Voraus :)

Ich vertraue Ihrem guten Urteilsvermögen, aber ich vertraue SO ungefähr so ​​weit ich einen Zweig werfen kann. Aber das ist OK. Ich wollte meine Nachricht zum Nutzen anderer senden, um zu sehen, wie eine Änderung des einzeiligen Codes diesen gesamten Thread hätte vermeiden können. Manchmal sagen Taten mehr als Worte. Prost.

@jhabdas So sehr ich Ihre Beiträge schätze, möchte ich Sie an unseren Verhaltenskodex erinnern, insbesondere an die folgenden Punkte:

  • Mit einladender und integrativer Sprache
  • Respekt gegenüber unterschiedlichen Standpunkten und Erfahrungen
  • Empathie gegenüber anderen Community-Mitgliedern zeigen

Ich entschuldige mich aufrichtig. Ich werde den Verhaltenskodex überprüfen und versuchen, ein guter Bürger der Gemeinschaft zu sein. Danke, dass du mich in die richtige Richtung gelenkt hast, @BYK.

Vielen Dank, dass Sie das behoben haben. 😍 🙇

Es war das Top - Thema mit großem Abstand in NPM

Diese Art des Projektmanagements ist einer der Gründe, warum ich zu Yarn gewechselt bin.

Angesichts der einfachen Behebung ist es eine Qual, wie viel Zeit und Mühe damit verschwendet wurde. 😢

Vielen Dank!

Hallo, danke für all die Bemühungen. Es ist weitaus besser, dass es jetzt auf meinem stdout statt auf stderror ist;). Trotzdem wird sogar das Info-Level Tonnen von Menschen hierher bringen. Und die einzige Ausgabe, die sie nach einer Stunde Lesen von Problemen erhalten, ist, dass sie für den Moment damit leben müssen (wer kein Babel verwendet) und dass eine plattformspezifische Optimierung über optionale Abhängigkeiten möglich ist, jedoch mit Kosten von Paketmanager Warnungen an den Benutzer. Ich bin auf der Seite, dass dies nur auf Debug-Ebene ausgegeben wird.

@ Kubino , das ist ein tolles Feedback, danke! Wir sind uns bewusst, dass eine Verschiebung auf info Problem nicht ein für alle Mal beheben würde. Dafür hat @jhabdas tatsächlich einige Zeit aufgewendet, um es noch besser und allgemeiner zu machen, und einen RFC eingereicht . Möchten Sie dort Feedback geben und uns mitteilen, ob dieser RFC Ihre Bedenken berücksichtigt?

@BYK danke, dass du immer noch daran interessiert bist. Ich bin weit davon entfernt, Experte zu sein, und vielleicht habe ich es falsch verstanden. Sie weisen mich auf RFC hin, wo der Titel "Veraltete Warnungen für Unterpakete informativer machen" lautet. Ich denke, dass die Übermittlung von DEPRECATED-Warnungen an die Benutzer standardmäßig korrekt ist (obwohl es wahrscheinlich gut wäre, bestimmte Paketwarnungen zu unterdrücken).
Meine Sorge galt den OPTIONALEN Abhängigkeiten, die nur als Optimierung für eine konkrete Plattform dienen. Dort sehe ich sehr wenig Wert darin, die ansonsten so schöne, saubere Garnausgabe zu verschmutzen. Aber wie gesagt, ich bin kein Experte und ich bin mir nicht sicher, ob dies immer so klar zu bestimmen ist

@ Kubino muss kein Experte sein. Sie wissen, dass die Welt voll von selbsternannten Experten ist. Es ist also besser, zu behaupten, kein Experte zu sein, und vielleicht werden Sie am Ende einer sein 😀

Wie auch immer, ich hatte noch keine Zeit, diesen RFC vollständig zu lesen, aber ich denke, er fällt unter den Abschnitt label = "Interoperability" . Das heißt, wir sollten für diese Fälle einen Abschnitt optimization hinzufügen. Das heißt, lassen Sie uns die Diskussion über diese PR fortsetzen und ich denke, Sie sollten diesen Vorschlag dort machen und sehen, was @jhabdas darüber denkt.

@kubino Ich habe die RFC- Beschreibung

Der RFC ist ein Vorschlag, mit dem versucht werden soll, eine Reihe verwandter Anwendungsfälle zu beheben, die möglicherweise auftauchen, indem eine kleine (scheinbar nicht verwandte) Funktion eingeführt wird, die bei kreativer Verwendung dazu beitragen soll, Anforderungen zu erfüllen, wie Sie sie auch angesprochen haben Hinzufügen eines zusätzlichen Nutzens zu der großartigen Arbeit, die Yarn bereits für die Community geleistet hat.

Diskutieren Sie gerne und nutzen Sie Ihre Erkenntnisse, um den RFC weiter zu verbessern, da ich gelernt habe, dass mehr Erfahrung genauso viel oder mehr eine Belastung sein kann, wie es ein Vorteil beim Codieren sein kann.

@BYK Ich weiß, wohin du @jhabdas , eine generische Lösung ist der einzige Ausweg aus diesen Diskussionen. Die Kategorisierung von Nachrichten ist der erste Schritt, der alles andere ermöglicht. Lassen Sie uns die Diskussion im zugehörigen RFC fortsetzen. Vielen Dank!

Wenn es optional ist, "ein Zielbetriebssystem gegeben", sollte es nicht einmal die Stufe WARN sein. Der Autor sagt: "Wenn MacOS FSEvents verwendet, sonst nicht." Wenn Sie also auf einem anderen Betriebssystem als Mac installieren, warum überhaupt warnen? Es ist eher wie Info / Debug.

@robertjchristian Ich denke, das hat zwei Aspekte:

  1. fsevents nicht selbst Arbeit außerhalb von macOS so ein Versuch , es auf ein solches Betriebssystem zu installieren sollte eine Warnung oder einen Fehler drucken. Einige Pakete, die fsevents verwenden, hängen möglicherweise universell (falsch) von der API ab, ohne zu wissen, dass sie nur für MacOS verfügbar sind und dabei auf anderen Betriebssystemen funktionieren.
  2. Wenn fsevents für einige Pakete gilt, die nur unter macOS benötigt werden, sollten diese Pakete fsevents als nicht außerhalb von macOS zu installierend markieren können. Ein Fehler bei der Installation von fsevents unter macOS würde dann zu einem Fehler führen, aber unter anderen Betriebssystemen würde es nicht einmal einen Installationsversuch geben.

Das Kernproblem ist, dass die Behandlung von fsevents als optionale Abhängigkeit ein falscher Ansatz ist. Was fehlt, ist die Möglichkeit, fsevents unter macOS als erforderlich und unter anderen Betriebssystemen als vollständig ausgeschlossen und nicht nur optional zu markieren.

Ja, das wurde im Original-Thread mehrmals erklärt, anscheinend hat niemand zugehört:

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

Die Lösung wäre, die Unterstützung plattformspezifischer Abhängigkeiten hinzuzufügen.

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

Die 'richtige' Lösung besteht darin, eine Methode für bedingte Abhängigkeiten zu haben - eine Möglichkeit für ein Paket, anzuzeigen, dass eine oder mehrere seiner Abhängigkeiten auf einigen Plattformen nicht installiert werden sollten. Dies ist nicht dasselbe wie ein Paket, das sich selbst als plattformspezifisch beschreibt. Ein Paket weiß nicht, ob es optional ist oder nicht. Es kann also nur sagen: "Wenn Sie mich auf der falschen Plattform installieren, ist das ein Fehler."

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

Folgendes könnte npm tun:

  1. Ändern Sie optionale Abhängigkeiten und nicht unterstützte Nachrichten von WARN in INFO (was die meisten Leute wollen).
  2. Implementieren Sie plattformspezifische Abhängigkeiten (richtige Lösung)

Anstatt die Warnung auszublenden, hätten sie sie durch die Implementierung bedingter Abhängigkeiten ordnungsgemäß beheben sollen. Dafür muss jedoch die package.json-Spezifikation geändert werden. Ich stelle mir so etwas vor:

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

Eine andere Alternative ist für fünf Autoren:

Stellen Sie sicher, dass es nicht auf Nicht-OSX-Plattformen ohne Warnungen fehlschlägt. Nur eine INFO-Meldung über die Plattform wird nicht unterstützt

Aber das unterscheidet sich nicht wesentlich davon, die Warnung auf npm-Ebene zu verbergen.

Immer noch keine Antwort? Diese Warnung ist so ärgerlich.

An diesem Punkt bin ich versucht, nur einen Mac zu kaufen, um dies für weitere vier Jahre nicht zu sehen, obwohl ich das Betriebssystem verabscheue 👎

An diesem Punkt bin ich versucht, nur einen Mac zu kaufen, um dies für weitere vier Jahre nicht zu sehen, obwohl ich das Betriebssystem verabscheue 👎

Wenn Sie Software professionell entwickeln, kann ich keine bessere Investition empfehlen.

Warum eine Warnung anzeigen, wenn der Benutzer nichts tun muss, um sie zu korrigieren?

Alle, die argumentieren, die Warnung beizubehalten, denken bitte eine Sekunde nach. Wenn der Benutzer nichts tun kann, um diese Warnung zu korrigieren, warum wird sie angezeigt?

Es ist, als würde dein Partner dir sagen, dass sie hungrig sind, du bist wie ein Koch für dich selbst, sie werden es nicht tun, du kochst, sie werden nicht essen, aber nerv dich weiter, ich habe Hunger. Jedes Mal, wenn Sie Hallo sagen (npm install / garn), sagen sie, dass ich hungrig bin (WARN WARN WARN). Scheint mir sinnlos.

An diesem Punkt bin ich versucht, nur einen Mac zu kaufen, um dies nicht zu sehen

Meinst du, du wirst das auf dem Mac nicht sehen?
Nun, Sie werden es nicht tun, wenn Sie Docker verwenden:

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.

Ich denke, Sie hätten besseres Glück, Chokidar zu gabeln und fsevents von dort zu entfernen.
Der aktuelle Knoten bietet große Verbesserungen hinsichtlich der nativen Unterstützung von fs.watch in OS X.

Natürlich müssten Sie auch Dutzende von Paketen je nach Chokidar teilen

Versuchen Sie, sich hier zur Abwechslung zu beschweren:
https://github.com/paulmillr/chokidar/issues

Ich denke, Sie hätten besseres Glück, Chokidar zu gabeln und fsevents von dort zu entfernen.
Der aktuelle Knoten bietet große Verbesserungen hinsichtlich der nativen Unterstützung von fs.watch in OS X.

Klingt so, als wären wir doch auf derselben Seite . xD

Ja, ich nehme an, die einzige Möglichkeit zu warten, bis Chokidar die Unterstützung für Knoten 10 aufgibt. An diesem Punkt würde es unbrauchbar werden und andere Projekte beginnen, es fallen zu lassen.

@ Vanuan jüngste node.js Unterstützung für fs.watch ist immer noch Scheiße. Versuchen Sie es tatsächlich plattformübergreifend zu verwenden.

Wenn Sie sich über Installationswarnungen beschweren möchten, wenden Sie sich möglicherweise an Betreuer, die Pakete "veralten". Das ist verdammt nervig. Das ist in der Vergangenheit nicht passiert. Fsevents ist im Vergleich dazu viel weniger ein Problem.

Wird das einfach nie behoben?

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen