Yarn: Konkurrierende Sperrdateien führen zu einer schlechten UX

Fügen Sie config zu package.json hinzu, um anzuzeigen

Dies könnte ein guter Anwendungsfall für das Feld engine sein

Rundauslösung package-lock.json → yarn.lock → package-lock.json ist verlustbehaftet, aber das ist wahrscheinlich unwichtig. yarn.lock → package-lock.json → yarn.lock sollte nicht verlustbehaftet sein, AFAIK.

Aus der Sicht von npm bevorzuge ich die Option, dass, wenn yarn ein package-lock.json und kein yarn.lock sieht, es importiert und das package-lock.json . Und wenn npm ein yarn.lock und kein package-lock.json npm sieht, sollte es dasselbe tun und das `yarn.lock importieren und entfernen.

Dies würde es Benutzern beider Tools ermöglichen, nahtlos hin und her zu wechseln, ohne das Projekt des Benutzers in einem verwirrenden Zustand zu belassen (wo Dateien von beiden zu stammen scheinen).

Ich bin ein bisschen besorgt darüber, weil es bedeutet, dass weder package-lock.json noch yarn.lock Metadaten zu den Dateien hinzufügen können (Garn derzeit nicht, aber warum nicht) und einige entfernen Freiheit zu unseren Formaten dabei.

Dieses Problem wirft auch die Frage der Interoperabilität zwischen Yarn und npm im Allgemeinen auf, die ursprünglich in einem anderen Thread erörtert wurde. Ich bin der Meinung, dass der Versuch, zu interoperabel zu sein, uns beide verdienen könnte, da die Benutzer dann die Erwartung haben, dass alles genauso funktioniert Bei beiden Projekten ist dies meiner Meinung nach eine gefährliche Annahme (ein offensichtliches Beispiel ist, dass Arbeitsbereiche stillschweigend unterbrochen werden, wenn jemand npm in einem Projekt mit Arbeitsbereich ausführt).

@ yarnpkg / core, gedanken?

Ich mag die Idee von @ iarna, beide Tools von einer Sperrdatei zu migrieren
ein anderer wird automatisch installiert.
Es ist sinnvoll, die importierte Sperrdatei nach der Migration zu löschen, um dies zu vermeiden
Beide Paketmanager konkurrieren in einem Projekt.

Beide Tools könnten Warnungen drucken und möglicherweise eine Benutzeraufforderung erfordern, um fortzufahren.

Ich stimme auch Maels Argument zu, dass das Erreichen einer 100% igen Kompatibilität eine Sperre darstellt
Ich denke, wir sollten neue Funktionen als einmalig behandeln
Migrationspfad, das könnte eine eher kleine Funktion in install.js auf unserer sein
Seite.

Am Mittwoch, den 11. April 2018 um 21:49 Uhr schrieb Maël Nison [email protected] :

Ich bin ein bisschen besorgt darüber, weil es bedeutet, dass weder
package-lock.json oder yarn.lock können den Dateien Metadaten hinzufügen
(Garn derzeit nicht, aber warum nicht), wodurch unsere Formate frei werden
dabei.

Dieses Problem wirft auch die Frage der Interoperabilität zwischen Garn und Garn auf
npm im Allgemeinen, ursprünglich in einem anderen Thread besprochen - ich möchte es versuchen
zu interoperabel zu sein, könnte uns beide verdienen, da die Benutzer es dann tun werden
Ich habe die Erwartung, dass bei beiden alles genau gleich funktioniert
Projekt, das ich für eine gefährliche Annahme halte (ein offensichtliches Beispiel ist
Diese Arbeitsbereiche werden stillschweigend unterbrochen, wenn jemand npm auf einem ausführt
arbeitsplatzbasiertes Projekt).

@ yarnpkg / core https://github.com/orgs/yarnpkg/teams/core , Gedanken?

- -
Sie erhalten dies, weil Sie in einem Team sind, das erwähnt wurde.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/5654#issuecomment-380677110 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/ACBdWI9jnLJeFqH8v2T-AB74sQO1PMIjks5tntzrgaJpZM4TQ5-B
.

Pinging @imsnif, da er vor einigen Wochen Interesse an der Implementierung der Lösung "Convert the other lockfile" bekundet hat. Möglicherweise hat er inzwischen sogar einen funktionierenden Code.

Danke für den Ping!

Also ja, ich bin gerade dabei, genau daran zu arbeiten. Ich hatte vor, nächste Woche einen Garn-RFC zu schreiben und alle Beteiligten anzupingen.

Also kurz: Ich habe einige Arbeiten an der Konvertierung von yarn.lock <==> package-lock.json durchgeführt. Es gibt einige Verluste im Prozess, aber nur sehr wenige davon sind logisch. In meinen Augen ist dies völlig akzeptabel, wenn wir über das oben erwähnte Szenario der einmaligen Konvertierung sprechen. Wenn wir dies weiter diskutieren möchten, kann ich auf weitere Details eingehen.

Ich habe derzeit einen rudimentären Code, der dies tut: https://github.com/imsnif/synp
Es ist nicht 100% und basiert auf einem vorhandenen und aktuellen Ordner node_modules damit das Projekt konvertiert werden kann. Ich bin in der Endphase eines Umschreibens (in Zweig 2.0.0 ), das den Paketstatus von der Registrierung erhält (unter Verwendung der fantastischen pacote lib).

Sobald dies erledigt ist, möchte ich darüber sprechen, wie (und ob?) Wir dies genau in yarn und npm implementieren möchten.

Würde gerne alle Gedanken dazu hören.

In meinen Augen ist dies völlig akzeptabel, wenn wir über das oben erwähnte Szenario der einmaligen Konvertierung sprechen

Ich denke nicht, dass es so häufig sein wird. Ich könnte mich irren, aber ich denke, der häufigste Anwendungsfall sind Projekte mit Yarn, und einer der Entwickler kopiert / fügt den Befehl aus einer README-Datei ein, um eine Abhängigkeit hinzuzufügen, indem er npm anstelle von yarn dabei.

In diesem Zusammenhang bin ich immer noch nicht davon überzeugt, dass es eine gute Sache ist, Daten zu verlieren und das Paketlayout stillschweigend zu ändern, indem sie versuchen, das Richtige zu tun - sie werden es wahrscheinlich erst bemerken, wenn die Dinge kaputt gehen (wir könnten eine Bestätigungsaufforderung haben, aber Ich erwarte, dass Leute, die diese Befehle kopieren / einfügen, auch blind die Installationsaufforderungen bestätigen. Schlimmer noch, es könnte auf ihrer eigenen Maschine funktionieren, aber auf der ihrer Kollegen brechen, sobald sie wieder zu Yarn wechseln.

@arcanis - Ich denke, alle Szenarien und

Ich sehe diese Funktion hauptsächlich in CI-Umgebungen, in denen sie meiner Meinung nach glänzen kann (wie im OP erwähnt). Zumindest denke ich, dass beide Tools die Sperrdatei des anderen Tools kennen sollten. Überlassen Sie die Einzelheiten, wann sie sich entscheiden, die Konvertierung vorzunehmen. Was denken Sie?

Ich sehe diese Funktion hauptsächlich in CI-Umgebungen, in denen sie meiner Meinung nach glänzen kann (wie im OP erwähnt).

Hast du ein beispiel CI-Systeme sollen sehr deterministisch agieren. Das versehentliche Festschreiben einer konvertierten Sperrdatei sollte zur PR-Zeit imo noch schlimmer abgefangen werden. CI ist dafür zu spät.

Zumindest denke ich, dass beide Tools die Sperrdatei des anderen Tools kennen sollten.

Könnte sein. Wenn ich die engine -Version verwende, um zu erzwingen, dass ein bestimmter Paketmanager für mich sauberer aussieht, müssten beide Projekte nur eine Liste exklusiver Engines führen (wie "Garn" kann bei "npm" nicht erfüllt werden und umgekehrt).

Meiner Meinung nach ist das Konvertieren der Sperrdateien im laufenden Betrieb auch nicht sehr skalierbar. Zum Beispiel haben wir bisher nur über die package-lock.json -Datei gesprochen, aber ich denke, pnpm hat eine eigene Sperrdatei namens shrinkwrap.yaml . Es wäre schön, wenn wir einen Weg finden könnten, mit beiden und jedem anderen Format umzugehen, das mit einer Klappe kommen könnte.

Ich sehe diese Funktion hauptsächlich in CI-Umgebungen, in denen sie meiner Meinung nach glänzen kann (wie im OP erwähnt).

Beachten Sie auch, dass npm, wenn ich es richtig verstanden habe, derzeit an einem CI-spezifischen, sehr leichten Paketmanager arbeitet, der möglicherweise nicht sehr gut mit Dingen funktioniert, die eine umfangreiche Geschäftslogik erfordern, wie z. B. einen Lockfile-Konverter.

In Bezug auf CI:
Mein erster Gedanke war: Warnung beim Hinzufügen eines neuen Pakets mit dem gegenüberliegenden Tool, Konvertierung bei einer Neuinstallation (oder konservativer: Standardmäßig bei einer Neuinstallation fehlschlagen und die Konvertierung ausführlich über einen Befehl import oder ein Konfigurationsflag zulassen zur Installation).

Wenn ich zuvor in einer gemischten npm / Garn-Umgebung gearbeitet habe, haben wir dies im Wesentlichen manuell mit Git-Historien gemacht. Es war ein mühsamer Prozess und ich bin sicher, dass wir damit nicht allein waren / sind.

Was die Skalierbarkeit betrifft:
Ich würde das auch gerne erklären.
Wenn die Konvertierung durchgeführt wird, wird ein logischer und physischer Zwischenpaketbaum (falls in der Sperrdatei eine vorhanden ist) erstellt. Bei der Konvertierung in die gewünschte Sperrdatei werden diese Bäume verwendet (oder mit vernünftigen Standardeinstellungen erstellt, falls wir von yarn konvertieren und keinen physischen Baum haben).
Auf diese Weise können wir problemlos zwischen anderen Sperrdateitypen konvertieren als (alles, was wir tun müssen, ist Konvertierungen in / von einem logischen / physischen Baum für jeden Typ bereitzustellen).

Dies ist offensichtlich ein wenig vor den Fähigkeiten des Tools, aber ich sehe die Implementierung nicht als großes Problem an.

(Was das neue ci-Tool von npm betrifft - ich verstehe, was Sie meinen, aber ich denke, das ist der aktuellen Diskussion ein wenig voraus?)

oder konservativer: Bei einer Neuinstallation standardmäßig fehlschlagen und die Konvertierung ausführlich über einen Importbefehl zulassen

Ja, ich wäre total dafür, diese Konvertierungslogik in den Befehl yarn import einzufügen. Es scheint eine nützliche Funktion zu sein, die in ein separates Paket extrahiert werden kann, wenn wir Garn-Plugins implementieren :) Meine Kommentare sind Konzentration auf das Standardverhalten, das wir übernehmen sollten.

Ab npm@6 sollten Sie in der Lage sein, package-lock.json -> yarn.lock verlustfrei zu konvertieren, ohne zuerst eine Installation ausführen zu müssen. Es sollte alle benötigten Daten, Bezeichner usw. enthalten (npm @ 6 's pkglock hat Versionsbereiche im Feld requires , die mit den Verwendungszwecken von yarn.lock übereinstimmen?)

Oh, und Sie müssen auch https://github.com/yarnpkg/yarn/pull/5042 versenden, bevor dies auch zutrifft, da npm in vielen Fällen nicht die sha1 im pkglock hat Fälle.

@arcanis - fantastisch! So würde eine PR mit:

1. Eine Warnung beim Installieren und Suchen einer package-lock.json -Datei
2. Eine Warnung beim Hinzufügen und Suchen einer package-lock.json -Datei
3. Hinzufügen der Möglichkeit zum Konvertieren von package-lock.json über den Befehl import (und Löschen der Datei danach)
   Akzeptabel sein? (Nur damit wir etwas haben, mit dem wir das Gespräch über Einzelheiten beginnen können)

@zkat - das ist großartig für npm@6 ! Wenn es nach mir geht, würde ich mich dafür entscheiden, dies zu verwenden und auf Manifestdateien zurückzugreifen, um alle Lockfile-Versionen zu unterstützen. Könnte ich fragen, ob Sie bereit sind, ein ähnliches (oder vielleicht etwas anderes) Verhalten für npm zu implementieren?

Beachten Sie auch, dass npm, wenn ich es richtig verstanden habe, derzeit an einem CI-spezifischen, sehr leichten Paketmanager arbeitet, der möglicherweise nicht sehr gut mit Dingen funktioniert, die eine umfangreiche Geschäftslogik erfordern, wie z. B. einen Lockfile-Konverter.

Wenn mit "derzeit arbeiten an" "versendet" gemeint ist, dann ja. =)

Wie Sie vorschlagen, liegt das Laden von yarn.locks derzeit außerhalb seines Bereichs (da es nicht weiß, wie Paketbäume zu gestalten sind), aber wenn wir alle eine Bibliothek haben, die dieses Layout ausführen kann, bin ich nicht dagegen, dass es das Laden unterstützt Garnschlösser. (Idealerweise ist dies eine Bibliothek, die zwischen ihm und Yarn geteilt wird.) In diesem Fall sollte die vorhandene Sperrdatei natürlich nicht entfernt werden. In Bezug auf Paketmetadaten ist es schreibgeschützt.

Eine Warnung beim Installieren und Suchen einer package-lock.json-Datei

Ich mache mir Sorgen, dass nur Warnungen, wenn eine nicht unterstützte Art von Sperrdatei vorhanden ist, nicht bei den Problemen helfen , die Heroku bei

Ich mache mir Sorgen, dass nur Warnungen, wenn eine nicht unterstützte Art von Sperrdatei vorhanden ist, nicht bei den Problemen helfen , die Heroku bei

Eine Warnung wäre eine Verbesserung, aber ein Fehler mit guten Nachrichten wäre ideal für Benutzer imo. Ich kann nur für mich selbst sprechen, aber ich habe mehrere Projekte, einige, die Garn verwenden, und einige, die npm verwenden, und ich finde mich oft dabei, das falsche für dieses Projekt einzugeben. Ein schneller Fehler bedeutet, dass ich sofort den verwenden kann, den ich von Anfang an haben sollte.

Wenn es eine Warnung ist, sollte sie groß und offensichtlich sein. IME-Benutzer sind ziemlich geschult, um zu erwarten, dass die Ausgabe ihres Paketmanagers ignoriert wird, solange es funktioniert.

Ich habe mich an einige Leute gewandt, die mehr Erfahrung mit Anfängern von Entwicklern haben, die hoffentlich erfahren, wie diese Erfahrung für jemanden aussieht, der gerade erst anfängt.

CI-Systeme sollen sehr deterministisch agieren. Das versehentliche Festschreiben einer konvertierten Sperrdatei sollte zur PR-Zeit imo noch schlimmer abgefangen werden. CI ist dafür zu spät.

Genau. Idealerweise befindet sich die Anwendung zum Zeitpunkt des Eintreffens beim Build / CI-Dienst nicht in einem unbestimmten Zustand. Die einzige Möglichkeit, den Build in diesem Fall nicht zu verfehlen, bestand darin, dass der Benutzer seine Präferenz in package.json angeben konnte, aber diese Lösung belastet den Benutzer auch stärker.

Ich mache mir Sorgen, dass nur Warnungen, wenn eine nicht unterstützte Art von Sperrdatei vorhanden ist, nicht bei den Problemen helfen , die Heroku bei

Es würde ihnen helfen, indem es die Benutzer warnt, dass sie etwas tun, was sie wahrscheinlich nicht wollen, bevor sie tatsächlich auf Heroku drängen. Ich bin mir nicht sicher, wie sehr sich die Zahlen tatsächlich ändern würden, aber das können wir in ein paar Wochen überprüfen und sehen, ob wir noch weiter gehen müssen. Und da die erforderlichen Änderungen relativ gering sind, könnte dies eine gute erste Iteration sein.

Ehrliche Frage für diejenigen, die eine Warnung vorschlagen: Gibt es eine Situation, in der es kein Fehler wäre, yarn install oder yarn add während ein package-lock.json vorhanden ist? Das Gleiche gilt für npm install und yarn.lock

Die Migration von npm zu Garn oder von Garn zu npm fällt mir ein. Ich würde es vorziehen, Reibung zu vermeiden, wenn man andere Paketmanager ausprobieren möchte.

Beachten Sie auch, dass sich Warnungen und Fehler nicht gegenseitig ausschließen oder zumindest nicht mit dem Feld engine . Projekte ohne angeheftete Paketmanager können eine Warnung drucken, und Projekte mit angehefteten Paketmanagern können Fehler verursachen. Auf diese Weise können Benutzer frei von einem Paketmanager zum anderen wechseln, bis sie ihre Wahl treffen und ihre package.json entsprechend konfigurieren.

Ein weiterer Vorteil des Engine-Feldes besteht darin, dass Sie sicher wissen, welche Version des Paketmanagers verwendet werden muss. Ich denke, es ist irgendwo konfigurierbar, aber mit diesem System wäre es Teil des regulären Workflows.

Ein weiterer Vorteil des Engine-Feldes besteht darin, dass Sie sicher wissen, welche Version des Paketmanagers verwendet werden muss. Ich denke, es ist irgendwo konfigurierbar, aber mit diesem System wäre es Teil des regulären Workflows.

Gibt es ein engine Feld oder beziehen Sie sich auf engines ? Ich kann keine Dokumente finden, die sich auf engine beziehen. Entschuldigung, wenn mir etwas fehlt.

Wir unterstützen die Angabe von Versionen im Feld engines : https://devcenter.heroku.com/articles/nodejs-support#specifying -an-npm-version

Ex:

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

Es gibt einige Bedenken, die ich habe, wenn ich dies verwende, um zu bestimmen, welcher Paketmanager verwendet werden soll:

• So sieht es heute aus: Eine nicht triviale Anzahl von Benutzern hat sowohl npm als auch yarn definiert oder eine npm-Version, aber dann haben sie eine yarn.lock . Zukünftige Versionen von npm und yarn könnten dies erzwingen, aber Benutzer, die nicht häufig aktualisieren, werden die aktuellen Versionen noch lange verwenden.

• Die meisten Benutzer berühren diese Konfiguration nie. Sie haben eine alte Boilerplate gegabelt, auf der Node 0.10 , obwohl sie alles verwenden, was sie von nodejs.org auf ihren Computer heruntergeladen haben. Dies verursacht eine nicht triviale Anzahl von Problemen bei Heroku.

• Teams koordinieren häufig nicht, welche Versionen sie installiert haben. Die Version von Node oder npm oder Garn, die sie installiert haben, ist oft die aktuelle Version, als sie mit einem Projekt begannen oder als einer von ihnen das letzte Mal pleite ging und sie zur Neuinstallation zwang. Nicht, dass dies ideal wäre, aber ich verstehe, dass die Mehrheit der Benutzer von npm / Garn Anfänger sind, und dies stellt eine neue Hürde für den Einstieg dar.

Beispiel: "Ich habe das Beispiel-Hallo-Welt-Projekt geklont, Node von https://nodejs.org heruntergeladen und es hat nicht funktioniert."

Alles, was gesagt wurde, ich würde lieben, lieben, lieben, wenn die Tools strenge Versionen erzwingen und es in engines . Es würde viele der Fehler verhindern, die ich jeden Tag sehe, aber das fühlt sich wie eine viel, viel größere Veränderung an.

Alles in allem würde ich lieben, lieben, lieben, wenn die Tools strenge Versionen durchsetzen und in Motoren aufzeichnen würden. Es würde viele der Fehler verhindern, die ich jeden Tag sehe, aber das fühlt sich wie eine viel, viel größere Veränderung an.

AFAIK Yarn setzt dieses Feld strikt durch, es sei denn, Sie übergeben eine Flagge, um dies zu deaktivieren.

Teams koordinieren häufig nicht, welche Versionen sie installiert haben. Die Version von Node oder npm oder Garn, die sie installiert haben, ist oft die aktuelle Version, als sie mit einem Projekt begannen oder als einer von ihnen das letzte Mal pleite ging und sie zur Neuinstallation zwang.

Dies ist ziemlich gefährlich, insbesondere bei Verwendung von Garn, da es nur die Konsistenz über dieselben Hauptversionen von Garn garantiert.

Nicht, dass dies ideal wäre, aber ich verstehe, dass die Mehrheit der Benutzer von npm / Garn Anfänger sind, und dies stellt eine neue Hürde für den Einstieg dar.

Wie wäre es mit Yarn (und auch npm, wenn ihnen die Idee gefällt), das einen "yarn": "^<current_version>" -Eintrag in das engines -Feld einfügt, um etwas Sicherheit ohne zu viel Reibung einzuführen? Wir können dies automatisch hinzufügen, wenn yarn init , yarn import oder wenn wir eine Sperrdatei von Grund auf neu erstellen.

Ich weiß nicht viel über Garn, aber ich denke, die beste Lösung wäre, einen package-lock.json Parser zu Yarn hinzuzufügen und keinen yarn.lock erstellen, falls vorhanden.

Ich denke, dass das Endziel darin bestehen sollte, ein Lockfile-Format zwischen Yarn und npm zu teilen.

@thatlittlegit Dann freuen Sie sich über https://github.com/yarnpkg/yarn/pull/5745 . (npm macht dasselbe in umgekehrter Reihenfolge, sodass wir an einem Ort landen, an dem es keine Rolle spielt, mit welcher Art von Sperrdatei Sie arbeiten oder welches Tool Sie auswählen.)

Bearbeitet, um hinzuzufügen: Ein einzelnes Lockfile-Format ist meines Erachtens kein wahrscheinliches Ergebnis, da es unterschiedliche Kompromisse zwischen den Lockfile-Formaten gibt und kein Konsens darüber besteht, welches das beste ist. Ich denke, dass es ausreichend ist, wenn beide Tools in der Lage sind, die Sperrdateien des anderen zu verstehen.

Darüber hinaus gibt es eine Menge Vorteile, wenn mehrere aktiv verwendete Tools unterschiedliche Kompromisse eingehen, da Benutzeranwendungsfälle besser erfüllt werden können als mit einer einzigen allgemeinen Lösung.

@BYK Einige Motorfelds wären hier wahrscheinlich hilfreich:

In npm @ 1 und npm @ 2 hatten wir zusätzlich zu den engine -Feldern ein package.json namens engineStrict . Wenn engineStrict wahr wäre, würde das Engine-Feld als _Resolution Constraint_ verwendet, und bevor wir den Semver-Bereich auf die Liste der Versionen angewendet hätten, würden Versionen mit inkompatiblen Engines herausgefiltert. Auf diese Weise können Sie beispielsweise npm install foo und [email protected] selbst wenn [email protected] veröffentlicht wurde, wenn [email protected] auf Ihrer Plattform nicht unterstützt wurde. Dies scheint wünschenswert, war aber in der Praxis sehr verwirrend, insbesondere weil die Dokumente auf der Website nur für die neueste Version waren.

Wenn engineStrict falsch war, wurde die Auflösung ohne Berücksichtigung der Engine-Felder durchgeführt und Warnungen ausgegeben, wenn das Ergebnis nicht kompatibel war.

Es gab AUCH eine engine-strict Konfigurationsoption, die dasselbe tat wie die package.json -Eigenschaft, sie jedoch auf ALLE Pakete anwendete.

Ab npm @ 3 haben wir die Unterstützung für die Eigenschaft engineStrict package.json eingestellt und das Verhalten der Konfigurationsoption engine-strict geändert. Die Konfigurationsoption wandelt jetzt die Warnungen, die Sie damit erhalten, in Fehler um, hat jedoch keinen Einfluss auf die Auflösung.

Die engine -Felder werden nicht nur für das Projekt der obersten Ebene, sondern auch transitiv erzwungen. Die Einführung eines yarn Engine-Flags würde bedeuten, dass Abhängigkeiten nur mit Garn installiert werden können, und ich glaube nicht, dass dies hier der Fall ist.

Da wir in der nächsten Version von yarn die Möglichkeit haben sollten, package-lock.json in yarn.lock zu importieren, möchte ich noch einmal auf das Warn- / Fehlerproblem eingehen.

So wie ich das sehe: Ich glaube nicht, dass es einen guten Grund für ein einzelnes Paket gibt, sowohl eine package-lock.json als auch eine yarn.lock Datei zu haben. Die meisten Projekte, die ich gesehen habe und die dies wissentlich haben, betrachten es als ein Problem, das behoben werden muss und nicht als eine gewünschte Situation (aber ich bin natürlich offen für Korrekturen).
Wie ich aus der obigen Erklärung von engine keine gute Lösung, um explizit anzugeben, welchen Paketmanager ein Paket verwendet.
IMO, dies ist eine Situation, die einen ausführlichen Fehler erzeugen sollte, der den Benutzer auffordert, entweder eine Datei zu löschen oder sie zu konvertieren.

Ich denke jedoch, dass es eine deutliche Veränderung wäre, einen solchen Fehler zu erzeugen. Auf der Garnseite würde ich vorschlagen, mit einer Warnung (wie oben erwähnt) zu beginnen und dieses Verhalten langsam zu verwerfen, bis zur nächsten Hauptversion, in der es in einen Fehler geändert wird (möglicherweise ein Konfigurationsflag hinzufügen, das es beiden Dateien ermöglicht) gleichzeitig existieren).

Was denken alle? @jmorrell , @BYK , @arcanis , @iarna?

Es scheint mir seltsam, dass jede Art von Projekt angeben sollte, welches Paketverwaltungstool verwendet werden soll. Korrigieren Sie mich, wenn ich falsch liege, aber ich sehe Yarn als Ersatz, der hauptsächlich von den Vorlieben des Endbenutzers abhängt. Versucht Yarn, NPM vollständig als De-facto-Standard zu ersetzen, oder versucht es, nebeneinander zu existieren?

@BrainBacon Sie profitieren nur dann von gesperrten Abhängigkeiten, wenn jeder denselben Paketmanager verwendet, der dieselbe Sperrdatei respektiert und dieselbe Semantik verwendet. Wenn ein Projekt ein yarn.lock und jemand dann ein npm install , kann diese Person immer noch andere Abhängigkeiten haben. Nein, es hängt leider nicht von den Vorlieben des Endbenutzers ab - vorzugsweise verwendet jeder in einem Projekt denselben Paketmanager.

Dies bedeutet auch, dass es nicht sinnvoll ist, zwei Sperrdateien in einem Projekt zu haben. Es ist unwahrscheinlich, dass sie sich in denselben Abhängigkeitsbaum auflösen und den Mitwirkenden unklar machen, welchen Paketmanager sie verwenden sollen.

(Das Drop-In-Ersatzteil war besonders dann zutreffend, wenn npm keine Sperrdateien erstellt hat, da dort keine Informationen verloren gingen. Es gilt auch immer noch, wenn # 5745 wirklich bedeutet, dass Yarn jetzt eine Sperrdatei basierend auf package-lock.json erstellen kann

Korrigieren Sie mich, wenn ich falsch liege, aber ich sehe Yarn als Ersatz, der hauptsächlich von den Vorlieben des Endbenutzers abhängt.

Garn ist in Bezug auf die exponierte API kein direkter Ersatz. Das yarn add <pkg> vs npm install <pkg> ist ein offensichtliches Beispiel für etwas, bei dem wir Dinge anders machen. Wir haben in der Regel den gleichen Funktionsumfang, aber am Ende sind es zwei verschiedene Tools, und manchmal haben wir unterschiedliche Lösungen für dasselbe Problem.

Das yarn.lock vs package-lock.json ist einer dieser Unterschiede, und ich glaube, weder Yarn noch npm sind daran interessiert, einen einzigen zu verwenden, da sie unterschiedliche Informationen enthalten.

Auf der Garnseite würde ich vorschlagen, mit einer Warnung zu beginnen (wie oben erwähnt)

Damit wäre ich einverstanden. Etwas wie:

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.

Möchte jemand eine PR eröffnen?

Ich würde gerne eine PR öffnen, die eine Warnung hinzufügt :)

Ist die gewünschte Endlösung hier ein hilfreicher Fehler, wenn package-lock.json existiert + yarn import ? Mein Verständnis war, dass @iarna befürwortete, dass jedes Tool die gegenüberliegende Sperrdatei entfernen / konvertieren sollte, wenn es automatisch existiert.

Jede Lösung wäre eine signifikante Verbesserung für die Benutzer, aber ich denke, es wäre am besten, wenn sowohl Garn als auch npm dieselbe Strategie wählen würden (obwohl dies nicht unbedingt erforderlich ist, wenn keine Übereinstimmung besteht und die Leute sich stark dafür fühlen).

@jmorrell - Mein Verständnis war, dass wir uns darauf geeinigt haben, dass eine automatische Konvertierung hier eine schlechte Idee ist.

Meistens, weil es schwierig ist zu wissen, wie das Delta zwischen den beiden Sperrdateien aussehen soll.
Z.B. Wenn ich die obige Warnung als Entwickler sehe, möchte ich wahrscheinlich herausfinden, wann die andere Sperrdatei erstellt wurde, welche Pakete hinzugefügt wurden, die nicht zu meiner Hauptsperrdatei hinzugefügt wurden, und sie dann hinzufügen. Möglicherweise wird die Option import als Referenz verwendet, aber nicht unbedingt.

Ich hoffe, die npm Leute sind sich einig?

Im Idealfall möchte ich, dass die Warnung etwas darüber enthält, dass es sich um eine veraltete Situation handelt (bei der Formulierung nicht sicher) und dass zukünftige Garnversionen einen Fehler verursachen. Vielleicht Link zu einer detaillierten Dokumentation darüber und wie man es angeht. @arcanis - denkst du, dass es machbar ist, oder warning Verhalten bleiben?

Wenn beide Tools error mehreren Sperrdateien ein

@arcanis npm add <pkg> ist vollkommen gültig und macht das, was Garn macht 👼

Was pkglock vs yarnlock angeht, bestand die ursprüngliche Absicht von package-lock.json darin, ein Format zu erstellen, das alle Daten enthält, die jeder Paketmanager benötigt. Tatsächlich kann pkglock ab npm@6 transparent in ein yarn.lock konvertiert werden, ohne ein Installationsprogramm auszuführen, da es einen vollständigen Baum mit allen relevanten Metadaten beschreibt. Wir haben das _absichtlich_ gemacht (wie das Feld requires ) und wir haben sowohl das Yarn- als auch das pnpm-Team um Feedback gebeten, um sicherzustellen, dass alles, was wir getan haben, ausreicht, um beide entweder als importierbare Sperrdatei oder zu verwenden als alternative Option. yarn.lock ist leider eine verlustbehaftete Teilmenge, daher ist die Umkehrung nicht wahr, aber wir werden trotzdem Dinge hinzufügen, um sie zu importieren. npm würde sogar Garn-berechneten Baumformen gehorchen (im Gegensatz zu Garn, das dies nicht tun würde).

Tatsächlich kann pkglock ab npm @ 6 transparent in ein yarn.lock konvertiert werden, ohne ein Installationsprogramm auszuführen, da es einen vollständigen Baum mit allen relevanten Metadaten beschreibt.

Ich glaube nicht, dass es möglich ist (aber vielleicht irre ich mich, zögern Sie nicht, auf ein Missverständnis hinzuweisen). Die Garn-Sperrdatei unterstützt nicht mehrere Bereiche, die in eine einzige Version aufgelöst werden. Wenn Sie je nach lodash@^1.0.0 mehrere Pakete haben, verwenden alle genau dieselbe Version. Es ist nicht nur eine Optimierung, sondern auch, wie wir Dinge in unserer Sperrdatei codieren.

Da die npm-Sperrdatei ein Baum ist, kann diese Eigenschaft nicht garantiert werden, und mehrere identische Bereiche verwenden möglicherweise unterschiedliche Versionen (was in Ordnung ist, da durch Ausnutzung der Regeln für die Knotenauflösung möglicherweise etwas bessere Optimierungen möglich sind). Unter solchen Umständen wäre die Konvertierung von package-lock.json -> yarn.lock verlustbehaftet, da wir keine andere Wahl hätten, als sie zu einer einzigen zusammenzuführen.

Auf der anderen Seite kann eine Garn-Sperrdatei relativ problemlos in eine package-lock.json umgewandelt werden, da unsere Regeln eine strengere Teilmenge von Ihnen sind (unsere zusammengeführten Bereiche können ohne Verlust in einen Baum umgewandelt werden, ein Baum kann nicht umgewandelt werden ein zusammengeführter Bereich ohne Verlust). Beachten Sie, dass ich nur über den Abhängigkeitsbaum selbst spreche. Ich bin mit Ihren Metadatenfeldern nicht vertraut.

Um ehrlich zu sein, bin ich mir nicht ganz sicher, ob wir dasselbe oder etwas ganz anderes sagen, ich wollte nur ein bisschen die Situation klären 🙂

Im Idealfall möchte ich, dass die Warnung etwas darüber enthält, dass es sich um eine veraltete Situation handelt (bei der Formulierung nicht sicher) und dass zukünftige Garnversionen einen Fehler verursachen. Vielleicht Link zu einer detaillierten Dokumentation darüber und wie man es angeht.

@imsnif Ich bin nicht davon überzeugt, dass dies ein Fehler in Nicht-CI-Umgebungen ist (keine Frage zu CI - dies sollte definitiv einen Fehler auslösen). Ich würde es vorziehen, bei einer Warnung zu bleiben, die einfach den aktuellen Status beschreibt und erklärt, warum dies nicht ideal ist.

Eine gute Sache ist, dass @jmorrell uns genaue Metriken liefern kann, um festzustellen, ob die Warnung ausreicht, und basierend darauf werden wir unseren nächsten Schritt wählen.

Ist die gewünschte Endlösung hier ein hilfreicher Fehler, wenn package-lock.json existiert + Garnimport?

Ja, zusammen mit dem Modus "Upgrade auf Fehler bei CI" * Ich denke, es ist ein vernünftiger erster Schritt!

(* Dies existiert noch nicht, ich werde es in der # 5773 Yarn 2.0 WG erwähnen)

@arcanis - Über Sperrdateien: Ich denke, was @zkat bedeutet (aber bitte @zkat korrigiert mich, wenn ich falsch verstehe ), ist, dass package-lock.json den physischen und logischen Baum speichert, während yarn.lock speichert nur den logischen Baum. Wie bereits erwähnt, gehen beim Konvertieren von package-lock.json => yarn.lock => package-lock.json die physischen Baumdaten verloren. IMO ist dies in den meisten Fällen in Ordnung, es gibt jedoch Ausnahmen: z. gebündelte Abhängigkeiten.

Meine persönliche Meinung ist, dass beide Paketmanager von der Synchronisierung ihrer Erstellung eines physischen Baums profitieren können. Aus dem, was ich gesehen habe, können wir wahrscheinlich einige genau definierte Regeln extrahieren, wie ein physischer Baum erstellt wird, und beide folgen ihnen (idealerweise mit einem Modul, das von allen Beteiligten verwaltet wird). Ich denke, dies wird beide das Kompatibilitätsproblem lösen, einige Probleme, die yarn mit gebündelten Abhängigkeiten hat, während jeder Paketmanager dennoch seine einzigartigen Macken behalten kann. (Zugegeben, ich bin ziemlich neu in dieser Diskussion, daher gibt es möglicherweise Dinge, die mir nicht bewusst sind - ich entschuldige mich, wenn ich einige schlafende Hunde wecke).

Zu dem vorliegenden Problem: vorzubringen , und wenn Sie nicht einverstanden sind, können wir die Warnungen für mich beibehalten:
Obwohl es in der Tat sehr wichtig ist, dass dies auf CI-Ebene abgefangen wird, denke ich, dass ein Fehler dort (im Durchschnitt) erheblich schwerer zu debuggen ist als ein Fehler in der lokalen Umgebung des Entwicklers.
Wenn ein Entwickler in seiner lokalen Umgebung einen Fehler erhält, weil er das falsche Tool verwendet, geht er (wahrscheinlich) nicht einmal einen Schritt weiter. Sie sagten einfach "Ups" und benutzten das andere Werkzeug. Dies spart enorm viel Zeit, anstatt es nach der Entwicklung eines Features und dem anschließenden Zurückverfolgen im CI abzufangen.
Eine Warnung (wie bereits erwähnt) wird möglicherweise in einigen anderen Fällen verschluckt, die Entwickler ignorieren, wenn der Exit-Status 0 ist.
Was denken Sie?

Außerdem - in der oben beschriebenen Situation könnte die "fremde" Sperrdatei verständlicherweise in .gitignore abgelegt werden, sodass das CI nicht einmal die Möglichkeit bekommt, davon zu erfahren. Als zerstreuter Entwickler könnte ich denken: "Nun, es gibt mir eine dunkle Warnung in meiner lokalen Umgebung, aber es besteht CI - also ist es wahrscheinlich nur ein lokales Problem für mich - na ja."

Eine Warnung (wie bereits erwähnt) wird möglicherweise in einigen anderen Fällen verschluckt, die Entwickler ignorieren, wenn der Exit-Status 0 ist.

Mein Punkt ist, dass diese Bestätigung nicht durch Daten gestützt wird, obwohl wir eine Möglichkeit haben, einige zu sammeln, um dann eine fundierte Entscheidung zu treffen. In diesem Zusammenhang erscheint mir die Wahl der radikaleren Option, die den Arbeitsablauf der Menschen unterbricht, etwas vergeblich und potenziell schädlich

Außerdem denke ich, dass Sie die User Story "Ich verwende einen Paketmanager und möchte einen anderen ausprobieren" übersehen, die meiner Meinung nach für alle Beteiligten sehr wichtig ist, sowohl für Paketmanager als auch für Benutzer. Es wäre nicht großartig, wenn die Leute nicht in der Lage wären, npm 6 aus ihrem Garnprojekt auszuprobieren (oder umgekehrt, Garn aus ihrem npm-Projekt auszuprobieren).

Meine persönliche Meinung ist, dass beide Paketmanager von der Synchronisierung ihrer Erstellung eines physischen Baums profitieren können.

Dies ist ein anderes Thema, aber ich bin anderer Meinung. Ich denke, es gibt ein Missverständnis, dass Garn npm ist, was falsch ist. Wenn Sie ein Projekt über einen speziellen Befehl in ein anderes importieren möchten, bin ich dafür, aber das stille Konvertieren (oder Lesen) von Sperrdateien aus einem Drittanbieterformat ist ein Rezept für eine Katastrophe:

• Konfigurationsdateien werden ignoriert
• Beim nächsten Hinzufügen / Entfernen eines Pakets wird der physische Baum unterbrochen
• Alle Funktionen, die nur für einen Paketmanager gelten, funktionieren nicht (Arbeitsbereiche, Überschreibung der Auflösung, Link:, ...).

Mein Punkt ist, dass diese Bestätigung nicht durch Daten gestützt wird, obwohl wir eine Möglichkeit haben, einige zu sammeln, um dann eine fundierte Entscheidung zu treffen. In diesem Zusammenhang erscheint mir die Wahl der radikaleren Option, die den Arbeitsablauf der Menschen unterbricht, etwas vergeblich und möglicherweise schädlich

Richtig - es wird nicht von Daten unterstützt. Ich spekuliere hier definitiv (sorry, wenn ich das nicht betont habe). Während wir möglicherweise ein Gefühl für den Trend des Warnfixes bekommen, können wir nicht ein Gefühl dafür bekommen, wie bequem dies für Benutzer ist und ob es eine bequemere Lösung gibt. Wenn wir uns auf Daten verlassen, gibt es meines Erachtens kein anderes Ergebnis als "Es gab absolut keine Änderung der Heroku-Bereitstellungsfehlerrate", das uns zur pauschalen Fehlerlösung führen wird.

Ich stimme zu, dass es ziemlich wichtig ist, die Arbeitsabläufe der Menschen nicht zu unterbrechen. Aus diesem Grund habe ich den Fehler als brechende Änderung in 2.0.0 , mit einem Wortlaut in der Warnung, der den Benutzer darauf hinweist, dass diese Situation veraltet ist. Ich denke auch, dass wir die Verwendung eines --force- oder config-Parameters zulassen können, um dieses Verhalten zu überschreiben. (Ich glaube, dies spricht auch Ihr Problem mit dem anderen Paketmanager an?)

Dies ist ein anderes Thema, aber ich bin anderer Meinung. Ich denke, es gibt ein Missverständnis, dass Garn npm ist, was falsch ist. Wenn Sie ein Projekt über einen dedizierten Befehl in ein anderes importieren möchten, bin ich dafür, aber das stille Konvertieren (oder Lesen) von Sperrdateien aus einem Drittanbieterformat ist ein Rezept für eine Katastrophe

Ich denke, Sie äußern hier wichtige Bedenken, auf die ich gerne eingehen möchte. Aber wie Sie sagen, ist dies ein anderes Thema und ich möchte das Gespräch nicht entgleisen lassen. Vielleicht können wir es in einer separaten Ausgabe diskutieren?

Ich denke, das Gespräch hier wurde ein wenig entgleist, deshalb möchte ich es mit einigen Erläuterungen und einer Zusammenfassung aufräumen:

1. Garn und npm haben unterschiedliche Auflösungs- und physische Baumerstellungsstrategien. Dies ist ein Schlüsselfaktor für beide Projekte.
2. Sowohl yarn.lock als auch package-lock.json Dateien wurden mit Blick auf bestimmte Ziele erstellt. Soweit ich sehen kann, stimmen diese Ziele nicht vollständig überein, sondern weisen einige Überschneidungen auf.
3. Der Unterschied in diesen Zielen macht ein Format anderen im Allgemeinen nicht überlegen, sie tauschen nur verschiedene Dinge aus.

Auf dieser Grundlage denke ich, dass die Beibehaltung beider Formate für Innovationen und die Erfüllung unterschiedlicher Anforderungen von entscheidender Bedeutung ist. Erforderlich ist die Gewährleistung der Projektportabilität bei minimalem Datenverlust zwischen Paketmanagern, ohne dass dem anderen eine bestimmte Strategie für Paketmanager auferlegt wird, um kostenlose Experimente zu ermöglichen.

Ich sehe die Bestätigung und Warnung vor anderen Sperrdateien zusammen mit der ordnungsgemäßen Konvertierung mit einer klaren Meldung darüber, was erhalten bleibt und was verloren geht, als einen großen Wert für die Benutzer auf jeder Seite. Die Frage hier in dieser Ausgabe ist nun, was der beste Ablauf für Benutzer ist, die eine Paketsperrdatei in ihrem Repo haben, wenn sie Garn ausführen .

Es sieht so aus, als ob die automatische Konvertierung potenziell gefährlich ist und eine fehlerhafte Installation ohne Ausweg bestimmte Personen verletzen kann. Wie wäre es, wenn eine Konfiguration festgelegt werden muss, damit Garn weiß, dass eine Paketsperrdatei im CI-Modus vorgesehen ist? Dies ist ein Signal der Entwickler an Garn: "Ich weiß, was ich tue, bitte versuchen Sie nicht, mich vor Unstimmigkeiten zu schützen."

Gedanken?

Wie wäre es, wenn eine Konfiguration festgelegt werden muss, damit Garn weiß, dass eine Paketsperrdatei im CI-Modus vorgesehen ist? Dies ist ein Signal der Entwickler an Garn: "Ich weiß, was ich tue, bitte versuchen Sie nicht, mich vor Unstimmigkeiten zu schützen."

@ BYK - hört sich toll an. Mit einem Zusatz: Wie @arcanis mich hier und bei Zwietracht überzeugt hat, kann es sinnvoll sein, auch im Nicht-CI-Modus eine Warnung hinzuzufügen, wenn das Konfigurationsflag nicht gesetzt ist. Damit Entwickler die Möglichkeit haben, zu wissen, dass ihr CI-Build möglicherweise fehlschlägt, bevor sie pushen (und sich auch vor package-lock.json in .gitignore schützen).

@arcanis wie @imsnif erwähnt: pkglock enthält sowohl das logische als auch das physische Layout des Baums. Wenn Sie der logischen Version des Baums folgen (die die Bereiche enthält, aus denen wir dedupiert haben), können Sie einen speicherinternen Garnblock ohne Installation oder Ausführung der Installationslogik erstellen. Nur Baumsuchen :)

Aus den Versionshinweisen zu NPM 5:

Eine neue, standardisierte Lockfile-Funktion für die paketübergreifende Kompatibilität (package-lock.json)

Es scheint, dass das NPM-Team package-lock.json als universelle Lösung bewirbt; Ist es (technisch) möglich, sich dieser Kraft anzuschließen?

Eine Lösung, die ich vorschlagen möchte, wäre "nur package-lock.json wenn es bereits existiert". Auf diese Weise "migrierte" NPM von Shrinkwrap zu einer Lock-JSON-Datei.

Es scheint, dass das NPM-Team package-lock.json als universelle Lösung bewirbt. Ist es (technisch) möglich, sich dieser Kraft anzuschließen?

Wir haben es bereits besprochen. Bitte überprüfen Sie den Rest des Threads, falls Sie dies nicht getan haben. Dies wird in naher Zukunft nicht passieren.

Ich denke, Sie übersehen die User Story "Ich verwende einen Paketmanager und möchte einen anderen ausprobieren", die meiner Meinung nach für alle Beteiligten sehr wichtig ist

Dies ist wahrscheinlich keine häufige Sache, Kontextwechsel. Ich habe vor einiger Zeit Yarn ausgewählt und habe nicht zurückgeschaut. Ich denke, es ist besser, etwas Gewicht hinter die Ernsthaftigkeit zu werfen, warum die Sperrdateien dort sind. Machen Sie es zu einem Fehler, der deaktiviert werden kann, und nicht zu einer Warnung, die ignoriert wird. Wenn jemand eine Sperrdatei festschreibt, hat dies einen Grund.

Unsere Statistiken zeigen, dass die Mehrheit der Garnbenutzer auch npm verwendet. Gemischte Projekte sind ungewöhnlich, aber eine einzelne Person, die an mehreren Projekten arbeitet, von denen einige npm und einige Garn sind, ist ziemlich häufig. Um das Problem noch weiter zu verkomplizieren, sollten Sie Skripte installieren, die npm direkt ausführen.

Ich möchte Garn verwenden, aber die meisten Projekte, an denen ich arbeite, haben nur package-lock.json Dateien. Ich kann keine yarn.lock -Dateien hinzufügen. yarn import ist langsam und / oder kaputt. Derzeit meine
_nur_ Option ist, Garn wegzuwerfen und auf npm umzuschalten.

Ich verstehe, dass Garn von Nur-Garn-Entwicklern für Nur-Garn-Projekte hergestellt wird. Aber was ist mit dem Rest von uns?

Hey @Spongman - yarn import sollte nicht kaputt sein. Es sollte nun in der Lage sein, package-lock.json für Sie zu importieren. Wenn Sie Probleme haben, lassen Sie es uns bitte wissen!

Ich habe # 6103 gemacht

Hey @Spongman - Ich habe in der Ausgabe kommentiert, dass dieser spezielle Fall auf ein beschädigtes package-lock.json . Ich würde mich über weitere Probleme freuen.

npm kann diese package-lock.json -Datei problemlos verwenden. Garn muss widerstandsfähiger sein.

Beantwortete dies in der anderen Ausgabe - ich bitte darum, dass die Diskussion dorthin verschoben wird, um diese Ausgabe zum Thema zu halten. Vielen Dank!

Ich habe https://github.com/yarnpkg/yarn/issues/3614 (mit derzeit 254: +1: s) genau beobachtet und daran teilgenommen. Diese Ausgabe wurde nun geschlossen und die Diskussion hierher verschoben.

Wenn ich die praktischen Herausforderungen ignoriere, würde meiner Meinung nach die mit Abstand beste UX durch eine Option bereitgestellt, die nicht in der Zusammenfassung oben erwähnt, sondern von @thatlittlegit erwähnt wird:

Ich denke, dass das Endziel darin bestehen sollte, ein Lockfile-Format zwischen Yarn und npm zu teilen.

Was auch durch @BrainBacons Punkt gestützt wird:

Es scheint mir seltsam, dass jede Art von Projekt angeben sollte, welches Paketverwaltungstool verwendet werden soll.

Wiederum ignorierte @iarna in diesem Thread (und @jhabidas im anderen Thread ) das theoretische Gegenargument, das die praktischen Herausforderungen für eine Minute ignorierte:

Es gibt eine Menge Vorteile, wenn mehrere aktiv verwendete Tools unterschiedliche Kompromisse eingehen, da Benutzeranwendungsfälle dadurch besser erfüllt werden können als mit einer einzigen allgemeinen Lösung.

Persönlich denke ich nicht, dass dieses Argument in diesem Fall zutreffen sollte, wie ich in einem Kommentar zum anderen Thread (mit 95: +1: s, 2: -1: s) gemacht habe:

Ja, ich stimme zu, Yarn möchte seinen unabhängigen Raum so weit wie möglich beibehalten, damit es die Flexibilität hat, eine bessere Erfahrung zu bieten. Aus diesem Grund ist beispielsweise die CLI von Yarn absichtlich nicht mit den NPMs kompatibel.

Ich denke jedoch, dass Sperrdateien außerhalb des Bereichs liegen, in dem Yarn die Unabhängigkeit angemessen aufrechterhalten kann. package-lock.json und composer.lock werden neben package.json und composer.json in das Repository übernommen . Hierbei handelt es sich nicht um werkzeugspezifische Dateien, sondern um projektspezifische Dateien, in denen die genauen Abhängigkeitsversionen angegeben sind, mit denen das Projekt garantiert funktioniert.

...

Damit Garn ein nützliches Werkzeug ist, müssen Entwickler Standardmodellen in ihren Projekten folgen können, damit das Projekt werkzeugunabhängig bleibt. Aus diesem Grund wurde Yarn auf package.json und nicht auf einer eigenen Abhängigkeitsdatei aufgebaut.

Nachdem ich den größten Teil dieses Threads gelesen habe, stimme ich meiner anfänglichen Einschätzung immer noch zu - wenn Yarn weiterhin dieselbe package.json Abhängigkeitsdatei aus dem Repository verwendet, sollte es idealerweise dieselbe package-lock.json Datei in das Repository ausgeben Das Repository kann also werkzeugunabhängig bleiben. Wenn Yarn seine Abhängigkeiten von yarn.json anstelle von package.json lesen würde, würde ich diesen Punkt nicht weiter ausführen.

Ich glaube, wir sollten zugeben, dass dies die ideale Situation ist, die nahtlose Benutzererfahrung. Ich verstehe jedoch den anderen Punkt von

Ein einzelnes Lockfile-Format ist meines Erachtens kein wahrscheinliches Ergebnis, da es unterschiedliche Kompromisse zwischen den Lockfile-Formaten gibt und kein Konsens darüber besteht, welches das beste ist

(obwohl ich nicht der Meinung bin, dass "es ausreicht, wenn beide Tools in der Lage sind, die Sperrdateien des anderen zu verstehen").

Wenn das ideale Szenario, um zuzulassen, dass Repositorys werkzeugunabhängig sind, definitiv nicht erreichbar ist (und ich sehe die vielen Kommentare darüber, wie die verschiedenen Sperrdateien auf grundlegend unterschiedliche Weise erstellt werden und unterschiedliche Informationen enthalten), dann scheint es fast so, als würden wir uns auf den Weg machen schmackhaft, was ist:

• NPM / Yarn gibt Warnungen aus, wenn sie die Sperrdatei des anderen erkennen (und möglicherweise eine Konfigurationsoption, um daraus einen Fehler zu machen).
• Beide Tools bieten Mechanismen zum Konvertieren einer Sperrdatei in eine andere

Ich denke nicht, dass einer unter keinen Umständen die Sperrdatei des anderen konvertieren und löschen sollte. Dies würde bedeuten, dass neue Entwickler für immer von einem zum anderen und zurück konvertieren würden, je nachdem, welches Tool der Entwickler gerade verwendet (da sich zu viele Leute mit git commit -a ).

Ich stimme auch dem Punkt von @imsnif nicht zu:

Ich glaube nicht, dass es einen guten Grund für ein einzelnes Paket gibt, sowohl eine package-lock.json- als auch eine yarn.lock-Datei zu haben.

Ich denke, es ist anmaßend zu bestimmen, was ein Entwickler auf seinem Computer oder in seiner Produktionsumgebung ausführt. Es ist zumindest höflich, nicht restriktiver zu sein, als Sie sein müssen. Wenn Ihr Projekt immer nur von Ihrem Entwicklerteam ausgeführt wird und alle genau dieselbe Software ausführen, ist das großartig. Aber vielleicht haben Sie einen Entwickler, der es aus irgendeinem Grund viel einfacher findet, NPM als Yarn zu verwenden. Und insbesondere, wenn Sie Open Source-Software erstellen, möchten Sie es Community-Mitgliedern so einfach wie möglich machen, den Betrieb aufzunehmen. Da NPM und Yarn lediglich Tools zum Installieren derselben Abhängigkeiten von package.json , sollten sie einfach funktionieren. Ein Entwickler sollte in der Lage sein, package.json , ein Werkzeug zur Interpretation zu haben und sich keine weiteren Sorgen machen zu müssen. Was früher der Fall war, bevor dieser Lockfile-Konflikt alleine kam.

Hey @nottrobin - Ich glaube ich verstehe, woher du kommst. Wenn wir praktische Herausforderungen und philosophische Unterschiede ignorieren, wäre es für die Benutzer der verschiedenen Tools definitiv besser, wenn sie alle dieselbe Sperrdatei verwenden würden (dies ist natürlich meine persönliche Meinung).

Aber da wir diese praktischen Herausforderungen nicht ignorieren können und größtenteils zugestimmt haben, dass die philosophischen Unterschiede ihren Platz haben, denke ich, dass der Kompromiss, zu dem wir gekommen sind (der, den Sie oben skizziert haben), definitiv "gut genug" ist.

Beachten Sie, dass eine versteckte Annahme in diesem Kompromiss darin besteht, dass die Werkzeugauswahl pro Projekt und nicht pro Maschine oder Produktionsumgebung des Entwicklers getroffen wird.

Beachten Sie, dass eine versteckte Annahme in diesem Kompromiss darin besteht, dass die Werkzeugauswahl pro Projekt und nicht pro Maschine oder Produktionsumgebung des Entwicklers getroffen wird.

Ja, ich denke, das ist das, was mich am meisten beschäftigt - obwohl ich denke, dass es in dem oben beschriebenen Szenario immer noch möglich ist , dass ein Projekt sowohl Yarn als auch NPM unterstützt.

Ich denke, dass die beiden Projekte, wenn sie die Mission aufgeben, ein Projekt werkzeugunabhängig zu machen, letztendlich aufhören sollten, eine Abhängigkeitsdatei gemeinsam zu nutzen. Das Garn sollte auf yarn.json anstatt auf package.json . Alles andere ist nur chaotisch und verwirrend.

Wenn npm-Sperrdateien bereits eine Obermenge der von Yarn-Sperrdateien unterstützten Abhängigkeitsbeziehungen haben, warum nicht beide in Yarn unterstützen? Yarn könnte zu package.json wechseln und alle zusätzlichen Felder, die von Yarn gewünscht werden, könnten in Zukunft hinzugefügt werden (ähnlich wie einige SVG-Editoren wie Inkscape Editor-Metadaten verwalten). Dann könnte Yarn das gleiche Abhängigkeitsformat wie npm haben und wieder mit yarn.lock kompatibel sein, wodurch npm-Sperrdateien in eine beliebige Struktur konvertiert werden, die Yarn im Speicher verlieren möchte.

Ich denke, dass die beiden Projekte, wenn sie die Mission aufgeben, ein Projekt werkzeugunabhängig zu machen, letztendlich aufhören sollten, eine Abhängigkeitsdatei gemeinsam zu nutzen. Das Garn sollte auf yarn.json anstatt auf package.json . Alles andere ist nur chaotisch und verwirrend.

Vielleicht, vielleicht auch nicht. Dies würde sicherlich einen massiven Bruchwechsel des Werkzeugs (Garns) erfordern. Weniger radikale Veränderungen mit direkteren und messbareren Vorteilen wurden übergangen.

Ich sage nicht, dass es eine schlechte Idee ist, ich sage nur, dass ich es nicht für praktisch halte.

Ich sage nicht, dass es eine schlechte Idee ist, ich sage nur, dass ich es nicht für praktisch halte.

Ich stimme zu, dass es eine große Frage zu sein scheint. Aber ich sage, dass dies ein zentrales Thema für das Projekt zu sein scheint.

Bisher war Yarn ein Tool, mit dem Entwickler anstelle von NPM Knotenabhängigkeiten für jedes Projekt mit einem package.json installieren konnten. Wie Sie bereits betont haben, müssen Projekte explizit zwischen Garn und NPM wählen. Das ist eine große Veränderung und sollte nicht versehentlich vorgenommen werden. Dies ist der Knackpunkt für diesen Anruf.

Meiner Meinung nach gibt es drei Möglichkeiten:

1. Seien Sie weiterhin ein Ersatz für NPM, indem Sie einen Weg finden, Garn an allen Schnittstellen auf Projektebene mit NPM auszurichten (Standardisierung der Sperrdatei).
2. Abweichend von NPM durch explizit unterschiedliche Schnittstellen auf Projektebene (z. B. yarn.json und yarn.lock )
3. Verdoppeln Sie die Bereitstellung der Hälfte der NPM-Schnittstelle und einer halben anderen Schnittstelle. Dies ist eigentlich das gleiche wie Punkt 2., aber während man auf die meisten Leute schaut, mag man Punkt 1.

Ich glaube, die dritte Option hier verwirrt den gesamten Knotenraum und schwächt beide Werkzeuge erheblich.

Es kann immer noch rückkompatibel sein. Yarn könnte nur einen eingebauten npm-Lockfile-Konverter haben. Wenn also package-lock.json angezeigt wird, bleibt es dort und konvertiert es im Speicher in das Format von yarn.lock. Soweit mir bekannt ist, kann npm dies nicht tun, da die Sperrdatei von Yarn weniger Informationen enthält als die von npm. Meiner Meinung nach ist es für Yarn am besten, mit npm zu standardisieren.

@nottrobin Ich denke, Sie sind in Ihrer Analyse jedoch größtenteils richtig:

Wie Sie bereits betont haben, müssen Projekte explizit zwischen Garn und NPM wählen. Das ist eine große Veränderung und sollte nicht versehentlich vorgenommen werden.

Ich denke, dies war schon immer der Fall oder zumindest für den Hauptvorteil, für den Yarn ursprünglich angepriesen wurde: die Reproduzierbarkeit von Abhängigkeitsbäumen. Sie können Ihre yarn.lock einchecken, aber das ist praktisch nutzlos, wenn andere Entwickler Abhängigkeiten hinzufügen / entfernen, ohne diese Sperrdatei zu berücksichtigen.

@nottrobin - Ich stimme @Vinnl zu. Wie ich oben erwähnt habe, möchte ich zwar niemandem sagen können, wie er arbeiten soll, aber ich denke, dass die Verwendung von Garn und npm für die Installation von Abhängigkeiten im selben Projekt ein Antimuster ist.

Obwohl beide Tools technisch viel Arbeit in diese Arbeit stecken könnten, denke ich nicht, dass wir als Betreuer dies fördern sollten. Es gibt unzählige andere Vorteile, austauschbare Sperrdateien zu haben (wie die verschiedenen Diskussionen in den verschiedenen Threads zeigen), aber ich denke nicht, dass dies einer von ihnen persönlich ist.

Dies ist jedoch praktisch nutzlos, wenn andere Entwickler Abhängigkeiten hinzufügen / entfernen, ohne diese Sperrdatei zu berücksichtigen.

Ja, ich nehme an, dass sich Yarn von Anfang an in diesem schlammigen Wasser befand - die Existenz von yarn.lock bedeutete bereits, dass es teilweise eine eigene Schnittstelle hatte. Ich denke, das war immer etwas chaotisch, was Garns Zweck diente, zu wollen, dass die Leute von NPM zu Garn gehen, aber nicht zurück.

Aber es war eine Entscheidung, die ich für mein Projekt besser getroffen habe, weil ich zumindest wusste, dass NPM immer noch vollständig unterstützt wird - da es überhaupt keine Sperre bot, würde es weiterhin so gut funktionieren wie immer.

Das hat sich geändert, weil NPM Abhängigkeiten sperrt. Wenn ich ein Projekt an Yarn binden möchte, halte ich jetzt yarn.lock auf dem neuesten Stand und nicht package-lock.json . Es ist also nicht mehr wahr, dass jemand NPM effektiv auf meinem verwenden kann Projekt.

Es hört sich so an, als würden Sie sagen, dass Garn nicht länger als Ersatz für npm gedacht ist? Dass es nur für reine Garnprojekte verwendet werden soll?

Ich denke, wenn das der Fall ist, dann sind Sie es allen schuldig, diese Tatsache auf der Garn-Homepage deutlich zu machen - verwenden Sie diese oder npm, nicht beide.

Es hört sich so an, als würden Sie sagen, dass Garn nicht länger als Ersatz für npm gedacht ist?

Das war es nie. Die Benutzeroberfläche ahmte npm etwas nach, um den Benutzern das Verständnis der Verwendung zu erleichtern, aber von Anfang an funktionierten einige Dinge anders. Der Hauptgrund, warum einige Leute dachten, es sei ein Ersatz, war, dass npm nur die zu vergleichenden Funktionen fehlten.

Jetzt, da npm einige Aspekte aufholt und beschließt, die Dinge anders zu implementieren, zeigt es einfach, dass wir unterschiedliche Ansätze haben und unterschiedliche Entscheidungen treffen (zum Beispiel ist die kürzlich implementierte Offline-Spiegelfunktion npm nicht mit unserer vorhandenen kompatibel). Kurz gesagt: Es war nie "sicher", es hat einfach versehentlich funktioniert.

Ich denke, wenn das der Fall ist, dann sind Sie es allen schuldig, diese Tatsache auf der Garn-Homepage deutlich zu machen - verwenden Sie diese oder npm, nicht beide.

Tatsächlich haben wir Migrationsanweisungen . Ihre Bemerkung hat mich darauf aufmerksam gemacht, dass es leider einen falschen Absatz enthält, der den Menschen den falschen Eindruck vermitteln könnte um sicherzustellen, dass jeder von den verschiedenen Funktionen profitieren kann, die vom Projekt verwendet werden können).

Das war es nie

ähm ... dann müssen Sie mit Ihren Marketingmitarbeitern sprechen. https://yarnpkg.com/lang/en/docs/

Yarn arbeitet direkt mit vielen Funktionen von npm zusammen, einschließlich des Paket-Metadatenformats, was eine schmerzlose Migration ermöglicht.

Wir haben keine Marketing-Leute, aber wir akzeptieren nette PRs 🙃

In diesem speziellen Fall klingt es jedoch nicht zu falsch. Wir arbeiten mit vielen Funktionen zusammen, nur nicht mit allen, und die Migration ist in den meisten Fällen schmerzlos (schlimmer noch, es ist ein yarn import entfernt).

Migration ist schmerzlos

Ich bin nicht wirklich an Migration interessiert. Ich suche nach dem, was hier versprochen wurde (diese Leute haben definitiv Marketing-Leute): https://code.fb.com/web/yarn-a-new-package-manager-for-javascript/

Es verfügt über dieselben Funktionen wie vorhandene Workflows und arbeitet gleichzeitig schneller, sicherer und zuverlässiger.

Garn ist heute nicht das.

AFAICT gibt es hier 4 Klassen von Benutzern:

• diejenigen, die nur Garn in ihren Projekten verwenden,
• diejenigen, die das Facbook-Verkaufsgespräch (oben) gekauft haben, aber noch keine dieser Sperrprobleme haben,
• diejenigen, die schmerzhaft versuchen, die Inkompatibilitäten zu umgehen, indem sie Sperrdateien bei Bedarf manuell konvertieren oder andere Hacks verwenden, um sie zum Laufen zu bringen,
• diejenigen, die gerade auf Garn verzichteten und wieder auf npm umstellten.

Ich möchte wirklich nicht in der letzten Kategorie sein, aber es scheint, dass ich dort gedrängt werde.

@ Spongman, was hält dich von dem letzten ab? Wir können es wahrscheinlich beheben;)

@Spongman Ich bin nicht mit Yarn verbunden, also kann ich ein bisschen stumpfer sein: Es macht wirklich keinen Sinn, in dieser Ausgabe zu sagen, dass Sie denken, dass der Wortlaut falsch ist. Wenn Sie der Meinung sind, dass der Wortlaut falsch ist, rufen Sie diese Seite in GitHub auf, klicken Sie auf die Schaltfläche Bearbeiten und senden Sie eine Pull-Anfrage mit besserem Wortlaut. arcanis hat oben deutlich gemacht, dass sie dafür offen sind.

(Ich denke, Sie können den Blog-Beitrag wahrscheinlich nicht bearbeiten, aber die Website ist hier wahrscheinlich die wichtigste.)

Ich kann den Antworten von @imsnif und @arcanis entnehmen , dass die offizielle Position hier zu sein scheint, dass Yarn "nie beabsichtigt" war, weiterhin nahtlos mit NPM zusammenzuarbeiten.

Aber ich stimme @Spongman voll und ganz zu, dass dies der Eindruck ist, den Yarn gemacht hat, und ich glaube wirklich nicht, dass dies zu dieser Zeit ein Unfall war. Das war sein Genie - Sie hätten Geschwindigkeit, Sicherheit usw. verbessern und gleichzeitig die offiziellen NPM-Standards vollständig unterstützen können.

In beiden Fällen macht dieses Problem die Position von Yarn zu diesem Thema für mich viel klarer als zuvor, und natürlich können die Betreuer von Yarn wählen, welche Richtung sie wählen.

Aber ich denke, Sie unterschätzen die Anzahl der Personen, die Garn verwendet haben, drastisch, gerade weil sie der Meinung waren, dass es die Kompatibilität mit NPM (auf Projektebene) beibehält und den Wechsel sonst nie vorgenommen hätte. Ich glaube, dass die 254: +1: s und 10: heart: s auf https://github.com/yarnpkg/yarn/issues/3614 und die 57 Upvotes zu " Soll ich yarn.lock und package-lock.json begehen?" Dateien? "machen dies reichlich klar.

Wenn Yarn an dieser Front jegliche Verantwortung aufgibt, wird es meiner Meinung nach nicht nur

Ehrlich gesagt verstehe ich das Problem, das Sie haben, wenn Sie nur Garn oder nur npm verwenden, wirklich nicht. Was Sie sagen, ist im Grunde "Hey, ich kann mein Team nicht zwingen, Garn zu verwenden, also werde ich sie zwingen, npm zu verwenden". Das ergibt für mich keinen Sinn. Wenn Sie die Funktionen von Yarn verwenden, lassen Sie alle Benutzer Yarn verwenden. Wenn Sie die Funktionen von npm verwenden möchten, lassen Sie alle Benutzer npm verwenden. So einfach ist das.

Dazwischen bedeutet, dass zumindest Ihre Builds in Ihrem Team nicht konsistent sind, was, wie bereits erwähnt, gegen die Prämisse von Yarn verstößt. Einer Ihrer Ingenieure könnte anfangen, Arbeitsbereiche zu verwenden, und es würde funktionieren, aber bei npm brechen. Gleiches gilt für den Offline-Spiegel. Gleiches gilt für die Abhängigkeitsauflösungen. Schlimmer noch, da einige Felder bis npm völlig unbekannt sind, würde es stillschweigend das Falsche tun.

In Bezug auf die Kommunikation wird im fb-Blogbeitrag kein Drop-In-Ersatz erwähnt. Lassen Sie mich den Teil zitieren, in dem Garn eingeführt wird. Es heißt wörtlich , dass es den Workflow ersetzt. Ich denke, Sie waren verwirrt über die "bleibt mit der npm- Registrierung kompatibel", was ein fairer Punkt ist, den Sie zu npm bringen sollten, nicht zu uns (es gibt die npm cli, die npm-Registrierung und natürlich npm Inc selbst).

Yarn ist ein neuer Paketmanager, der den vorhandenen Workflow für den npm-Client oder andere Paketmanager ersetzt und gleichzeitig mit der npm-Registrierung kompatibel bleibt.

Was hält dich von dem letzten ab? Wir können es wahrscheinlich beheben;)

@zkat Das ist hilfreich, danke.

@nottrobin - Ich kann nicht für die ursprünglichen Absichten des Garns sprechen, weil ich zu der Zeit nicht da war. Ich arbeitete jedoch in einer gemischten Garn / npm-Umgebung mit mehreren Dutzend Repositories.

Ich kann sagen, dass allen beteiligten Entwicklern damals völlig klar war, dass die Wahl von Garn / npm eine Pro-Repo-Wahl war, genau wie die Wahl von Express / Hapi, Mobx / Redux usw. Dies wurde mit npm noch deutlicher

Wenn ein Entwickler eine Abhängigkeit mit dem falschen Tool installiert, führt dies bereits vor npm @ 5 zu einem Durcheinander, da diese Abhängigkeit nicht konsistent gesperrt wird. Es verursachte Probleme in unseren verschiedenen Umgebungen und allen Beteiligten war klar, dass dies ein Fehler war *.

Mir ist klar, dass dies verwirrend sein kann - und ich verstehe, dass dies möglicherweise nicht jedem ohne eigenes Verschulden zu 100% klar ist, aber ich halte es nicht für richtig, das Tool drastisch zu ändern, um diesem Missverständnis gerecht zu werden. So wie ich es sehe, Garn ist ein direkter Ersatz für npm auf einem Pro-Repo und nicht pro-box - Basis.

* Zugegeben, diese besondere Situation mehrerer Repos ohne Arbeitsbereich mit gemischten Garn / npm-Werkzeugen war auf menschlicher Ebene nicht ideal und nicht auf technischer Ebene für genau diese Fehlerpotentiale und wurde schließlich behoben. Ich verwende dieses Beispiel hier, um zu zeigen, dass die beiden Werkzeuge bei korrekter Annäherung nebeneinander arbeiten können.

Ehrlich gesagt verstehe ich das Problem, das Sie haben, wenn Sie nur Garn oder nur npm verwenden, wirklich nicht.

Ja, Sie @arcanis und @imsnif haben klargestellt, dass Sie nicht verstehen. Der einzige Punkt, den ich mache, ist, dass viele Leute (siehe: +1: s) die gleiche "falsche" Interpretation gemacht haben und wollen, dass Yarn neben NPM arbeitet, unabhängig davon, ob Sie das verstehen oder nicht. Wenn Garn nicht das Werkzeug für uns ist, soll es so sein.

(Nur ein letzter Punkt - @imsnif Es ist völlig lächerlich, ein Tool zum Installieren von Knotenabhängigkeiten mit einer Projektauswahl wie Express vs Hapi, Mobx vs Redux zu vergleichen. Dies sind grundlegende Merkmale Ihrer App. Wenn Sie den offensichtlichen Unterschied nicht erkennen können, Kein Wunder, dass du meinen Standpunkt nicht verstehst.)

Jedenfalls bin ich jetzt fertig. Ich denke, ich habe meinen Standpunkt so gut wie möglich dargelegt.

Bei Open-Source-Projekten geht es nie darum, "das Team" zu zwingen, Garn oder npm zu verwenden. Es ist eine Frage, was für alle am bequemsten ist. In der realen Welt ist npm König. Wenn Garn in einer npm-Welt nicht gut spielen kann, ist es tot.

^ Dies

Ich fürchte, das ist auch ein Missverständnis. Im vergangenen Jahr stieg Yarn von 20% der Gesamtzahl der Anfragen an die npm-Registrierung auf 40% im April . Das letzte Mal, als ich die Statistiken hörte (direkt von den npm-Leuten, da unsere Statistiken kürzlich kaputt gingen, als die npm-Registrierung an Cloudflare ging), waren es ungefähr 48% der Anfragen. In der realen Welt existieren Garn und npm schlicht und einfach nebeneinander.

Ich würde mich jetzt freuen, wenn wir zum vorliegenden Thema zurückkehren könnten: Wer ist bereit, eine PR zu schreiben, um eine Warnung zu schreiben, wenn wir bei der Installation eine package-lock.json -Datei erkennen? Vielen Dank.

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

Genial: heart_eyes:

Können wir dieses Problem zwischen dieser und Ihrer Arbeit an yarn import dann schließen?

Ich dachte, wir würden warten, bis @jmorrell uns einige Statistiken darüber gibt, wie sich dies auf das Problem auf Heroku auswirkt, damit wir entscheiden können, ob dies ausreicht oder wir etwas ändern möchten (Warnung / Fehler usw.).

EDIT: afaik die Warnung wurde noch nicht veröffentlicht, so dass wir noch etwas Zeit haben zu warten.

Ich fürchte, das ist auch ein Missverständnis.

Wie das? Das Verkehrsaufkommen um npm sagt nichts darüber aus, ob das Projekt Open Source ist oder nicht.

Eine genauere Bewertung wäre, zu zählen, welche Github-Projekte 0,1 oder 2 haben (yarn.lock, package-lock.json). persönlich habe ich noch nie ein Open-Source-Projekt (von nennenswerter Größe) auf Github gesehen, das eine yarn.lock-Datei und _no_ package-lock.json enthält (mit Ausnahme des Offensichtlichen).

IMO, wenn Sie separate Sperrdateien behalten möchten, sollten BEIDE Paketmanager die Sperrdatei und den FEHLER des anderen erkennen (möglicherweise mit einem Überschreibungsflag).

Alle - Ich bitte Sie, beim Thema zu bleiben und nicht direkt verwandte Kommentare offline zu schalten (z. B. unseren Discord-Kanal). Es gibt viele Leute, die diesen Thread abonniert haben, und fairerweise glaube ich, dass die Diskussion über npm <> Garn nicht hierher gehört. Vielen Dank!

Ich habe nicht das gesamte Profil gelesen, aber der IHMO-Benutzer sollte zumindest darüber informiert werden, dass Unklarheiten bestehen:

Wenn npm eine yarn.lock-Datei sieht, sollte npm Folgendes drucken:
"WARNUNG: Dieses Projekt scheint Garn zu verwenden. Vielleicht sollten Sie 'Garn' anstelle von 'npm install' verwenden."

Wenn das Garn die Datei package-lock.json sieht, sollte das Garn Folgendes drucken:
"WARNUNG: Dieses Projekt scheint npm zu verwenden. Vielleicht sollten Sie 'npm install' anstelle von 'yarn' verwenden."

Und wie oben vorgeschlagen, eine Möglichkeit, den Paketmanager (in package.json) zu "bevorzugen".

Ich kann sagen, dass allen beteiligten Entwicklern damals völlig klar war, dass die Wahl von Garn / npm eine Wahl pro Repo war, genau wie die Wahl von Express / Hapi, Mobx / Redux usw.

Das war mir überhaupt nicht klar. Bis jetzt dachte ich, es sei eine entwicklerlokale Wahl, und mehrere Entwickler könnten auf einem einzigen Repo koexistieren, wobei sie das verwenden, was sie möchten, während es ein wenig bequemer ist, nur eines konsistent zu verwenden. Die Beispiele für Express / Hapi usw. sind jedoch gut und machen deutlich, dass dies keine Wahl ist. Dies sollte mehr Sichtbarkeit haben.

Fügen Sie in package.json ein Feld hinzu, um anzugeben, welchen Paketmanager ein Projekt verwenden soll

"package-manager": "yarn"

Ich denke, dies ist die beste Lösung, wenn sie in allen Paketmanagern implementiert ist.

Die Paketmanager MÜSSEN sich dann zu 100% weigern, fortzufahren, wenn sie für das falsche Projekt aufgerufen werden, genau wie Sie einen Fehler erwarten würden, wenn Sie Redux benötigen, aber dann versuchen, Mobx-Funktionen darauf aufzurufen. Sie sollten einen Fehler und keine Warnung ausgeben und den Benutzer darüber informieren, wie er mit dem richtigen Paketmanager vorgehen soll.

Fügen Sie in package.json ein Feld hinzu, um anzugeben, welchen Paketmanager ein Projekt verwenden soll
"package-manager": "yarn"

Ich denke, dies ist die beste Lösung, wenn sie in allen Paketmanagern implementiert ist.

Wenn Sie möchten, dass npm dies berücksichtigt, empfehle ich Ihnen, eine Diskussion am geeigneten Ort zu eröffnen, aber ich werde sagen, dass mir diese Richtung nicht gefällt. Ich würde mir eine Konvergenz zwischen Paketmanagern und keine Divergenz wünschen.

Ich würde gegen ein neues "Paket-Manager" -Feld empfehlen, stattdessen die vorhandene Zeilengruppe engines empfehlen, die bereits Stand der Technik enthält.

Sowohl in der Garn- als auch in der npm-Dokumentation wird (nebenbei) die Verwendung von engines.npm und engines.yarn , um die Versionen anzugeben, von denen erwartet wird, dass sie verwendet werden. Das Garn wird sogar fehlerhaft, wenn die Garnversion engines.yarn nicht erfüllt.

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

Selbst wenn weder npm noch garn engines für den "konkurrierenden" Manager prüfen (was nett wäre), ist die Verwendung dieses Felds immer noch eine gute Möglichkeit, anderen Entwicklern mitzuteilen, welcher Manager voraussichtlich verwendet wird. (Wenn die Existenz von package-lock.json oder yarn.lock nicht ausreicht, um einen Hinweis zu geben)

Ich würde mir eine Konvergenz zwischen Paketmanagern und keine Divergenz wünschen.

Einverstanden. Entweder Konvergenz oder Ablehnung.

aber der derzeitige zweideutige, fehlerhafte Mittelweg ist schädlich.

Ich denke immer noch, dass nur das Auslösen eines Fehlers in Gegenwart der Sperrdatei der anderen die geringste Reibung für bestehende Projekte erfordern würde.

Wenn Sie möchten, dass npm dies berücksichtigt, empfehle ich Ihnen, eine Diskussion am entsprechenden Ort zu eröffnen

Danke, ich habe mich gerade angemeldet. Es gibt einen aktuellen Thread in diese Richtung: https://npm.community/t/npm-install-should-warn-about-the-presence-of-yarn-lock-files/1822

Ich stimme dafür, dass ich einen Punkt falsch mache, anstatt nur zu warnen. Ich bin mir also nicht sicher, ob ich an diesen Thread einen neuen anhängen soll.

Ich würde mir eine Konvergenz zwischen Paketmanagern und keine Divergenz wünschen.

Hier gilt das gleiche. Obwohl sie derzeit nicht kompatibel sind, ist die Divergenz bereits aufgetreten und verursacht bereits Reibung bei vielen Benutzern und Projekten.

Welche Konvergenz sich aus weiteren Gesprächen zwischen den Teams ergibt, wird einige Zeit in Anspruch nehmen. Wenn es eintrifft, können die vorgeschlagenen Fehler behoben werden und Benutzer können ohne Probleme mit dem Wechseln und Mischen von Paketmanagern beginnen.

Das Hinzufügen der Fehler vermeidet jetzt weitere Verwirrung und stoppt nicht die Bemühungen in Richtung Konvergenz.

Ich würde gegen ein neues "Paket-Manager" -Feld empfehlen, stattdessen die vorhandene Zeilengruppe "Engines" zu empfehlen, die bereits über den Stand der Technik verfügt.

Das klingt vernünftig. Ich bin an keine bestimmte Methode gebunden, um das Vorhandensein eines inkompatiblen Paketmanagers zu erkennen.

Zur Veranschaulichung ist mein Anwendungsfall insbesondere gatsbyjs. Die Situation ist genau die gleiche wie von @gaearon hier berichtet :

Das Erstellen von React App-Benutzern ist äußerst verwirrend, da ihr Projekt mit Yarn erstellt wird (sofern Yarn auf dem System vorhanden ist). Anschließend folgen sie jedoch den Dokumenten einer Bibliothek, in der sie aufgefordert werden, npm zu installieren, und der den gesamten Baum wegbläst.

Um dieses Problem zu vermeiden, fügt Gatsby, obwohl es Garn verwendet, den Standardstartern ein package-lock.json . Aber dann haben Benutzer beide Sperrdateien und sehen Warnungen. Es ist einfach, einen von ihnen zu löschen, aber es verwirrt das Onboarding-Erlebnis.

Vielen Dank an alle für Ihre Eingabe.

@jmorrell - https://github.com/yarnpkg/yarn/pull/5920 wurde am 25. Juli in 1.9.2 veröffentlicht. Seit etwas mehr als einem Monat weiß ich, dass es nicht viel Zeit ist (und sicherlich nicht alle haben ein Upgrade durchgeführt) - aber haben Sie vielleicht einige Einblicke in die Double-Lockfile-Fehler auf Heroku seitdem?

@imsnif Danke für die E-Mail-Erinnerung! Entschuldigung, dass Sie das Update hier verpasst haben.

Hier ist eine grafische Darstellung der Anzahl der Apps, bei denen 2018 wöchentlich dieser Fehler aufgetreten ist.

(Ich habe die y-Skala überarbeitet, aber dies repräsentiert Hunderte von Entwicklern und zeigt den Trend.)

1. Der Rückgang im Juli ist auf ein nicht mit S3 zusammenhängendes Problem zurückzuführen

2. Betrachtet man den Trend nach dem 25. Juli, so scheint die Warnung einen erheblichen Einfluss auf die Anzahl der Personen gehabt zu haben, bei denen dieser Fehler aufgetreten ist. Ich bin etwas überrascht über das Ausmaß der Verschiebung.

@jmorrell - das ist wirklich toll!
Ich gebe zu, ich bin auch ziemlich überrascht darüber.

Ich denke (auf der Garnseite), dass dieses Problem als gelöst angesehen werden kann. Sind Sie einverstanden?

Ich denke immer noch, dass der Ratschlag, package-lock.json zu entfernen, um den Fehler zu beheben, irreführend ist - dies führt im Allgemeinen dazu, dass andere Paketversionen verwendet werden, und führt (wieder im Allgemeinen) zu Inkompatibilitäten und Brüchen. Dieser Rat ist auch nur für diejenigen nützlich, die Entscheidungen darüber treffen, welchen Paketmanager ein Projekt verwendet. Allgemeine Mitwirkende, die diesen Rat befolgen, werden ebenfalls auf Probleme stoßen.

IMO Wenn ein package-lock.json vorhanden ist und yarn nicht garantieren kann, dass die installierten Versionen mit denen übereinstimmen, die npm installieren würde, sollte dies mit einem Fehler fehlschlagen.

Nochmals vielen Dank für Ihre Eingabe @Spongman. Ich bin der Meinung, dass dies alles in dem (sehr langen) Thread über uns gut diskutiert wurde und ich denke nicht, dass es sinnvoll ist, es erneut zu starten. Ich denke, wir alle verstehen Ihre Position. Vielen Dank für Ihre Teilnahme.

Sofern @jmorrell mir in der nächsten Woche oder so nichts

@imsnif Dies ist immer noch der Hauptgrund, warum Node auf Heroku aufbaut, einschlägt und die

Ich habe seit npm keine Bewegung mehr gesehen, daher werde ich eine PR erstellen, die auch dort eine Warnung hinzufügt und sieht, dass sie akzeptiert wird.

Ich denke (auf der Garnseite), dass dieses Problem als gelöst angesehen werden kann. Sind Sie einverstanden?

Ich denke nicht, dass dies für Benutzer behoben wurde, und die Benutzererfahrung ist immer noch nicht großartig. Aber ich kann sehen, wie sich die Zahlen ändern, wenn npm auch einem Benutzer Feedback gibt, der diesen Fall trifft.

Ich überlasse es Ihnen, ob Sie dies schließen oder weitere Änderungen vornehmen möchten. Ich freue mich, in ein paar Monaten eine neue Ausgabe zu eröffnen, wenn dies für die Benutzer immer noch ein großes Problem darstellt.

@jmorrell - gestartet wird und sich sogar wiederholt, denke ich, dass es besser ist, es jetzt mit den Informationen zu schließen, die wir haben.

Wenn wir auch weiterhin ein Problem sehen, wenn npm ebenfalls eine Warnung bereitstellt, wäre ich definitiv bereit, die Fehlerdiskussion erneut zu starten (oder nach anderen Lösungen zu suchen). Bitte pingen Sie mich in diesem Fall persönlich an.

Vielen Dank, dass Sie dies angesprochen, dazu beigetragen und all diese Änderungen vorgenommen haben! Ich persönlich finde, dass Garn nach dieser Ausgabe besser ist.