Yarn: `--pure-lockfile` als Standard für `install` machen

Ich stimme zu. Es sollte eine Diskussion darüber geben, warum yarn install standardmäßig eine Sperrdatei schreibt, da dies im Widerspruch zum gesamten Sperrdateikonzept zu stehen scheint. Warum eine Sperrdatei haben, wenn sie standardmäßig keine Versionen sperrt?

Es gibt einen Fall für yarn install Schaffung eines lockfile wenn keines vorhanden ist, das heißt , wenn jemand ein Projekt Umwandlung verwenden yarn , aber die Gründe für die ist es immer das Schreiben nicht klar. Ich stimme der Meinung von @bestander zu , dass nur mutierende Aktionen die Sperrdatei standardmäßig aktualisieren sollten, dh add/upgrade/remove .

Sollte es eine Möglichkeit geben, die Sperrdatei ohne add/remove/upgrade zu ändern, z. B. in dem Szenario, in dem Sie Yarn aktualisieren und eine neue Sperrdateiversion verwenden?

Ich nehme an, die Option könnte umgekehrt werden

yarn install --save-lockfile

Am 17. Oktober 2016 um 18:53 schrieb James Ide [email protected] :

Sollte es eine Möglichkeit geben, die Sperrdatei ohne Hinzufügen/Entfernen/Aktualisieren zu ändern?
Beispiel: im Szenario, wenn Sie Yarn aktualisieren und es eine neue Sperrdatei verwendet
Ausführung?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/yarnpkg/yarn/issues/570#issuecomment -254282256 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ACBdWJLpdvqiwcBwqE4KB3x3f4oCn_nVks5q07YYgaJpZM4KSlSw
.

Das verwirrt mich auch. Was ist der Grund für das aktuelle Standardverhalten?

Afaik, es gab keine triftigen Gründe für das Standardverhalten.
Die Idee, nehme ich an, ist, die Lockfiles der Leute "immergrün" zu halten.

Übrigens PR ist willkommen

Ich denke, der Grund dafür war, dass Garn ursprünglich mit einem einzigen install Befehl entworfen wurde, der in install/add/upgrade

Also, um zu überprüfen, ob ich das richtig verstanden habe:

yarn installiert alle Abhängigkeiten und modifiziert auch die Lockfile. Auf einem CI-Server sollten Sie yarn install --pure-lockfile ?
Warum wird die Sperrdatei während einer Installation geändert? Da Sie nichts aktualisieren ... Yarn sollte die Pakete einfach wie in der Lockfile beschrieben installieren, oder?

Danke für die Erklärung!

Das Problem ist, dass, wenn die Sperrdatei standardmäßig rein ist, die Leute vergessen, sie zu aktualisieren, da dies ein separater Befehl wäre.

@kittens Sollte die Sperrdatei nicht nur beim Hinzufügen/Entfernen/Aktualisieren von Paketen aktualisiert werden? Diese sollten immer die Sperrdatei aktualisieren sowie eine Erstinstallation durchführen.

Das Problem ist, dass, wenn die Sperrdatei standardmäßig rein ist, die Leute vergessen werden, sie zu aktualisieren, da es ein separater Befehl wäre

Dass das ein Problem ist, hängt davon ab, was Sie für das Hauptziel eines Paketmanagers halten.

Meiner Meinung nach besteht eine der Rollen, die ein Paketmanager ausfüllt, darin, den Einstieg in die Entwicklung eines Projekts so einfach wie möglich zu machen. Ein einfaches yarn install sollte alle Pakete erhalten, die Sie benötigen, um mit der Entwicklung zu beginnen, ohne dass Verwirrung entsteht.

Mit npm ich viele Fälle von Entwicklern, die einem Projekt beigetreten sind, nur um festzustellen, dass ein Projekt auf ihrem Computer nicht funktioniert. Diese Fälle sind aufgrund vorübergehender Abhängigkeiten aufgetreten, die Versionen auf Versionen mit Breaking Changes stoßen oder einfach nicht dem Server folgen. Ich hatte gehofft, dass yarn diese Probleme lösen würde, aber wenn alle Entwickler eines Projekts yarn install --pure-lockfile ausführen sollten, um 100% sicher zu sein, dass das Projekt erstellt wird, dann ist das nicht so der Fall.

Eine weitere Rolle eines Paketmanagers besteht darin, Projekten die Kontrolle über ihre Abhängigkeiten zu geben. Wenn es standardmäßig rein gemacht wird, können Entwickler sich yarn outdated ansehen, um die veralteten Versionen zu sehen und dann die Änderungsnotizen zu überprüfen, um brechende Änderungen zu vermeiden. Dies würde Entwicklern die volle Kontrolle geben, um nur Versionen in einem bestimmten Release-Zeitrahmen zu pushen, anstatt Entwicklern zu verbieten, git commit -a auszuführen, um versehentliche Lockfile-Commits zu vermeiden.

Ich stimme allem zu, was @esphen sagt. Ich bin überrascht, dass das reine Verhalten in Yarn nicht der Standard ist – ich dachte, diese Art von Konsistenz sei der größte Vorteil von Yarn gegenüber NPM. Dies sollte der zwingendste Grund für den Wechsel von NPM sein, wie ich es sehe.

Hat uns total überrascht, als wir ein paar Tage lang yarn benutzten, als wir den Build kaputt machten. Ich dachte ehrlich gesagt, dass --pure-lockfile das Standardverhalten war, nachdem ich einen Großteil der Dokumentation gelesen hatte und darüber, wie es besser ist als npm mit Shrinkwrap. Bitte Standard festlegen :)

@ide Stellen Sie sich ein Szenario vor, in dem jemand nur npm verwendet und package.json aktualisiert. Wie wird yarn.lock aktualisiert?

Kann mir bitte jemand die Szenarien aufschreiben, die dazu führen, dass die Sperrdatei unerwartet geändert wird? Diese Änderung ist schwerwiegend und macht die Sperrdatei zu einem Bürger zweiter Klasse, indem sie explizite Aktualisierungen erfordert, was viel Aufwand bedeutet, sich daran zu erinnern, welche Operationen zu einer Aktualisierung führen usw.

Weitere Informationen zu oben: Unser Build hat Coffeescript von Github als Unterabhängigkeit. Coffeescript hat einige Commits verschoben und wir haben ein modifiziertes yarn.lock in unserem Build-Prozess erhalten, indem wir nur yarn install :

diff --git a/foo/yarn.lock b/foo/yarn.lock
index ec667fa..bb1f6ae 100644
--- a/foo/yarn.lock
+++ b/foo/yarn.lock
@@ -930,9 +930,9 @@ code-point-at@^1.0.0:
   version "1.6.3"
   resolved "https://registry.yarnpkg.com/coffee-script/-/coffee-script-1.6.3.tgz#6355d32cf1b04cdff6b484e5e711782b2f0c39be"

-"coffee-script<strong i="8">@github</strong>:jashkenas/coffeescript":
+coffee-script@jashkenas/coffeescript:
   version "1.11.1"
-  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/887052de079b2f0af9f080031a00bb7544eaca08"
+  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/0d132318ce8f7116a436d97db1f2a5c8b1dedf28"

 [email protected]:
   version "0.3.0"

Kann mir bitte jemand die Szenarien aufschreiben, die dazu führen, dass die Sperrdatei unerwartet geändert wird? Diese Änderung ist eine schwerwiegende und macht die Sperrdatei zu einem Bürger zweiter Klasse, indem sie explizite Aktualisierungen erfordert, was viel Aufwand bedeutet, sich daran zu erinnern, welche Operationen zu einer Aktualisierung führen usw.

Ich nehme yarn install als einen Befehl wahr, der node_modules für mich erstellt.
Es ist das Gegenteil von yarn add und yarn remove , die package.json, Garn.lock und Node_modules bereinigen.
Im Gegensatz zu add und remove laufe ich install 100 Mal häufiger, besonders in CI, wo ich nie mit Nebenwirkungen rechnen muss.

Beispiele, wenn ich nicht erwarte, dass sich etwas ändert:

1. Ich verwende Garn 0.15.0, meine Teamkollegen sind auf Garn 0.16.0.
   Da 0.16.0 jedes Mal Leerzeichen zwischen den Einträgen in Garn.lock hinzugefügt hat, wenn ich yarn install gegen von meinen Teamkollegen generierte Garn.lock ausführe, erhalte ich eine modifizierte Garn.lock-Datei, die ich nicht begehen muss.
   Und umgekehrt.
2. Meine anderen Build-Tools hängen von "garn.lock" als "Quelle der Wahrheit" des node_modules-Zustands ab. Wenn es sich unerwartet ändert, bekomme ich in meinen Builds keinen Determinismus

@kätzchen

Das Problem ist, dass, wenn die Sperrdatei standardmäßig rein ist, die Leute vergessen, sie zu aktualisieren, da dies ein separater Befehl wäre.

Stellen Sie sich ein Szenario vor, in dem jemand nur npm verwendet und package.json aktualisiert. Wie wird Garn.lock aktualisiert?

Wenn wir davon ausgehen, dass yarn install yarn.lock nicht aktualisieren sollte, dann sollte es auch fehlschlagen, wenn yarn.lock nicht synchron mit package.json , um die Tatsache hervorzuheben, dass ein yarn install --save-lockfile wird benötigt, um alles wieder zu synchronisieren.

+1 Garninstallation sollte das Garn.lock nicht mutieren

1. Der Debugger ist eine Oss-App. Wir möchten, dass Mitwirkende in der Lage sind, Garn zu installieren und die _guten_ Versionen zu erhalten. Wir haben Leute npm installieren lassen und sagen, dass es wegen transitiver Eigenschaften kaputt geht. Bei der Garninstallation wissen die Mitwirkenden Garninstallation und wissen nicht, was sie mit den Garnschlosswechseln tun sollen.

Ich mache mir keine Sorgen um die Aktualisierung der Sperrdatei. Im Idealfall würde Greenkeeper dies tun, wenn sich die Deps ändern, und wir könnten dann die Änderung der Sperrdatei zusammenführen.

Ich möchte dieses Thema mit den aktuellen Gedanken dazu aktualisieren. @kittens und ich denken beide, dass --pure-lockfile mehreren Gründen _nicht_ der Standard sein sollte.

Es beginnt damit, wie Leute Abhängigkeiten hinzufügen/entfernen/aktualisieren. Es gibt zwar Befehle dafür, aber es ist gängige Praxis, package.json entweder von Hand oder mit einem anderen Tool wie Lerna manuell zu aktualisieren.

Nachdem Sie das package.json manuell geändert haben, erwartet sowohl Yarn als auch npm, dass es beim Ausführen einer anderen Installation _syncs_ mit dem package.json . In diesem Sinne könnte yarn install fast in yarn sync .

Zum Thema Synchronisierung: Wenn Sie eine Installation mit neuen Abhängigkeiten ausführen, erwarten Sie, dass das Verzeichnis node_modules diese Änderungen widerspiegelt. Da yarn.lock als Assistent für node_modules , sollten Sie erwarten, dass es auf die gleiche Weise synchronisiert bleibt.

Ihr package.json ist die ultimative Quelle der Wahrheit, das ist Ihre Schnittstelle zum Garn, es ist Ihre Konfiguration und es ist das einzige, womit Sie sich jemals beschäftigen sollten. In einer idealen Welt legen Sie einfach Ihre yarn.lock und müssen dann nie wieder darüber nachdenken.

Nebenbei bemerkt glaube ich, dass viele Leute, die dieses Thema unterstützen, verwirrt darüber sind, was hier tatsächlich diskutiert wird.

Die standardmäßige Verwendung von --pure-lockfile bedeutet nicht, dass Yarn keine konsistenten und zuverlässigen Ergebnisse liefert. Dieselben package.json führen zu denselben yarn.lock was zu 100% zu denselben node_modules .

Wenn Sie Ihre package.json aktualisieren, werden Ihre yarn.lock Datei und dann Ihre node_modules Updates aktualisiert. Das ist eine ganz natürliche Ordnung der Dinge und das sollten wir auch beibehalten

In Bezug darauf, dass CI in der Lage ist, verschiedene Abhängigkeiten zu erhalten, wenn Sie Ihre package.json aktualisiert haben, aber yarn install nicht ausgeführt haben, um alles zu synchronisieren, was sicherlich jemand ansprechen wird (obwohl ich es nicht als ein Thema) - ich selbst und andere haben über die Integration von Garn zu verschiedenen CI - Tool sprechen, können wir leicht drücken für sie verwenden --pure-lockfile standardmäßig , wenn die Menschen es als großes Problem sehen.

Würden wir diese Änderung vornehmen, würde dies beim Ändern von Abhängigkeiten viel häufiger negative Auswirkungen haben. Aus den genannten Gründen sage ich, dass wir dieses Problem schließen sollten.

@thejameskyle Ich würde mich

1. Ein Entwickler hat ein package.json das eine Abhängigkeit enthält "foo": "^1.0.0"
2. Der Entwickler führt yarn install . Das foo Paket hat derzeit die Version 1.0.0 , also erstellt es eine yarn.lock Datei, die in [email protected]
3. Der Entwickler fügt Git yarn.lock .
4. Der Entwickler führt Unit-Tests auf seiner lokalen Kopie des Repositorys durch, alles funktioniert einwandfrei.
5. Der Entwickler schiebt sein Repo an CI (zB Travis).
6. CI läuft yarn install , aber foo wurde jetzt auf Version 1.1.0 aktualisiert, daher installiert Yarn [email protected] und überschreibt yarn.lock mit der neuen Version von foo
7. Das CI bricht, weil foo eine Breaking Change in Version 1.1.0

Hier ist eine ähnliche Situation:

1. Ein Entwickler hat ein package.json das eine Abhängigkeit "foo": "^1.0.0" , die als [email protected] gesperrt ist, und yarn.lock wird in Git gespeichert.
2. Unit-Tests funktionieren auf der lokalen Kopie des Repositorys des Entwicklers einwandfrei.
3. Ein Mitwirkender klont das Repository mit der Absicht, eine Änderung + Pull-Anfrage vorzunehmen.
4. Wenn der Mitwirkende yarn install ausführt, erhält er die Version [email protected] die bewirkt, dass yarn.lock aktualisiert wird.
5. Jetzt ist der Build des Mitwirkenden defekt, weil foo eine grundlegende Änderung in der Version 1.1.0

Ich denke, das sind die Situationen, über die sich die meisten Menschen Sorgen machen.

Wenn Sie also klarstellen könnten, dass das derzeitige Verhalten von yarn install die oben genannten Probleme nicht hat, würde dies meiner Meinung nach die meisten unserer Befürchtungen beseitigen. :+1:

Keine dieser Situationen trifft zu. Nur weil eine Abhängigkeit aktualisiert wurde, heißt das nicht, dass Sie sie erhalten, nur wenn Sie Änderungen an Ihrem package.json .

Ich werde dieses Thema nur schließen, weil es wirklich so aussieht, als ob dies die einzige Sorge der Leute ist, was, wie gesagt, kein wirkliches Szenario ist. Dieses Problem führt wahrscheinlich zu mehr Verwirrung.

Aber es hat das schlechte Verhalten, wenn eine Abhängigkeit von github installiert wird, wie ich oben berichtet habe

@adamchainz Das sollte separat behoben werden, wir können es leicht an den Commit

Keine dieser Situationen trifft zu. Nur weil eine Abhängigkeit aktualisiert wurde, heißt das nicht, dass Sie sie erhalten, nur wenn Sie Änderungen an Ihrem package.json .

@thejameskyle : Ich bin mir nicht sicher, ob ich verstehe, warum dies kein echtes Szenario ist. Könnten Sie bitte näher erläutern?

Stellen Sie sich eine Memoize-Funktion vor, bei der die Eingabe package.json und die Ausgabe yarn.lock .

1. Wenn Sie zum ersten Mal ein package.json , wird ein yarn.lock und das Ergebnis zwischengespeichert.
2. Wenn Sie das nächste Mal _that same_ package.json ausführen, ist das Ergebnis genau dasselbe, da es zwischengespeichert wird.
3. Wenn Sie die package.json ändern, haben Sie den Cache ungültig gemacht und jetzt werden die yarn.lock neu berechnet.

Worüber wir gerade sprechen, ist # 3 loszuwerden und stattdessen yarn.lock so zu behandeln, als ob es nicht durch das geänderte package.json ungültig gemacht worden wäre. Was für eine Memoize-Funktion wirklich seltsam wäre und für Yarn ein wirklich seltsames Verhalten.

Was mit einem Paket in Bezug auf Commits und neue Versionen passiert, _sollte_ irrelevant sein (wenn wir einen Fehler mit Git-Commits haben, sollten wir das separat beheben, aber es hat nichts mit diesem Problem zu tun).

Es ist komplexer, als ich es mir vorgestellt habe (jede Paketversion wird effektiv einzeln "auswendig gelernt", das Ändern der Version eines Pakets macht den Rest nicht ungültig), aber hoffentlich versteht jetzt jeder den Punkt.

@thejameskyle : Aus Gründen der Klarheit (und Neugierde) nehmen wir an, ich habe ein Projekt mit einer yarn.lock Datei und jemand zieht das Repository herunter. Ohne yarn install oder npm install auszuführen, fügt diese Person der Datei package.json eine neue Abhängigkeit hinzu und führt dann yarn install . Wird die vorhandene yarn.lock Datei in diesem Fall komplett ignoriert?

Es gibt eine Menge verschiedener Dinge, die hier vor sich gehen, die ich versuchen wollte zu entwirren (kein Wortspiel beabsichtigt).

Erstens haben die Leute eine Reihe verschiedener Anforderungen gestellt, die meiner Meinung nach unumstritten sind (und die einige der bestehenden Verhaltensfehler zu Fehlern machen, auf die ich gleich eingehen werde).

Aus dem ursprünglichen Fehlerbericht.

Die Konsistenz geht verloren, wenn die Sperrdatei je nach Umgebung (der derzeit installierten Garnversion) geändert wird.
Was ist das erwartete Verhalten?
Schreiben Sie nicht "Garn.lock" oder "Paket.json", wenn Sie Garn installieren.
Um Garn.lock zu aktualisieren, verwenden Sie Garn-Upgrade

Genauer gesagt sind die erwarteten Semantiken meiner Meinung nach:

• Wenn sich package.json seit der letzten Änderung von yarn.lock geändert hat, ist yarn.lock die Quelle der Wahrheit und sollte nicht aktualisiert werden.
• Wenn sich package.json seit dem letzten Mal geändert hat, yarn.lock geändert wurde, aktualisieren Sie yarn.lock so, dass es package.json erfüllt und aktualisieren Sie node_modules .
• Wenn yarn update wird, lösen Sie alle Abhängigkeiten erneut auf und holen Sie sich die neueste Version von allem, was die package.json erfüllt.

Das bedeutet, dass wenn ein Repository zum ersten Mal auf einer Maschine geklont wird und das yarn.lock eingecheckt wurde, es immer als die Quelle der Wahrheit behandelt werden sollte, und keine Updates für das yarn.lock generieren und springen direkt zum Abrufschritt.

Soweit dies nicht das aktuelle Verhalten von Garn ist, halte ich das für einen Fehler.

@esphen schrieb:

Ich stimme zu. Es sollte an erster Stelle diskutiert werden, warum Garn install standardmäßig eine Lockfile schreibt, da dies im Widerspruch zum gesamten Lockfile-Konzept zu stehen scheint. Warum eine Sperrdatei haben, wenn sie standardmäßig keine Versionen sperrt?

Ich denke, was damit gemeint ist, ist, dass Garn keine neue Lockfile schreiben sollte, wenn die vorhandene noch auf dem neuesten Stand ist. Ich stimme dem zu.

Ich stimme der Meinung von @bestander zu , dass nur mutierende Aktionen die Sperrdatei standardmäßig aktualisieren sollten, dh hinzufügen/aktualisieren/entfernen.

Das Hauptproblem hier ist, ob eine Änderung an package.json soll, dass yarn.lock aktualisiert wird. Meiner Meinung nach, wenn die Änderung an package.json von yarn.lock nicht erfüllt wird, muss es yarn.lock aktualisieren.

Eine wichtige Invariante von Lockfile-Systemen wie Garn ist, dass Entwickler bei Verwendung des normalen Workflows sicher sein können package.json nicht mehr synchron mit dem yarn.lock darf, ist dies nicht der Fall, und die einzige Möglichkeit, dies zu erkennen, besteht darin, dass menschliche Leser die yarn.lock sorgfältig lesen

Die meisten Benutzer denken am besten über die Lockfile nach, dass es sich um ein Artefakt des laufenden Garns handelt, das die genauen Versionen aller Pakete darstellt, die für das aktuelle package.json . Durch das Einchecken wird sichergestellt, dass andere Mitarbeiter, CI und Produktionscode dieselben Versionen verwenden.

@Guuz sagte:

Also, um zu überprüfen, ob ich das richtig verstanden habe:
Garn installiert alle Abhängigkeiten und modifiziert auch die Lockfile. Auf einem CI-Server sollten Sie Garn installieren --pure-lockfile verwenden?

Diese Frage spiegelt eine Meinung wider, die einige Leute in diesem Thread geäußert haben.

Cargo hat ein --locked Flag, das besagt, dass "wenn package.json nicht von yarn.lock erfüllt wird, ist es ein schwerer Fehler". Bundler hat ein ähnliches Flag ( --frozen ), das hinzugefügt wurde, als Heroku Bundler annahm, um Leuten einen schweren Fehler zu geben, wenn sie lokale Änderungen an ihren Gemfile und vergessen haben, die Gemfile.lock einzuchecken

Die Idee ist, dass Sie während Ihrer normalen Entwicklung in der Lage sein möchten, Änderungen an den package.json vorzunehmen und sicherzustellen, dass die yarn.lock synchron bleiben (um sicherzustellen, dass die angegebenen Versionen in package.json immer dem, was in der Praxis verwendet wird).

Aber bei der Bereitstellung ist es praktisch immer ein Fehler, abgewichen zu sein, weil dies bedeutet, dass Sie eine Änderung an package.json , einen lokalen yarn Befehl ausgeführt und vergessen haben, yarn.lock einzuchecken . Dies bedeutet, dass die Versionen in Ihrem package.json nicht mit den tatsächlichen Versionen übereinstimmen, die beim Ausführen der Anwendung verwendet werden , was, wie wir sagten, eine grundlegende Invariante von Garn verletzt.

@esphen sagte:

Meiner Meinung nach besteht eine der Rollen, die ein Paketmanager ausfüllt, darin, den Einstieg in die Entwicklung eines Projekts so einfach wie möglich zu machen. Eine einfache Garninstallation sollte alle Pakete erhalten, die Sie benötigen, um mit der Entwicklung zu beginnen, ohne dass Verwirrung entsteht.

Ich denke, das ist unstrittig.

Mit npm hatte ich viele Instanzen von Entwicklern, die einem Projekt beigetreten sind, nur um festzustellen, dass ein Projekt auf ihrem Computer nicht funktioniert. Diese Fälle sind aufgrund vorübergehender Abhängigkeiten aufgetreten, die Versionen auf Versionen mit Breaking Changes stoßen oder einfach nicht dem Server folgen. Ich hatte gehofft, dass Garn diese Probleme lösen würde, aber wenn die Erkenntnis lautet, dass alle Entwickler eines Projekts Garn installieren --pure-lockfile ausführen sollten, um 100% sicher zu sein, dass das Projekt erstellt wird, dann ist dies nicht der Fall.

Das Ausführen von yarn install --pure-lockfile bedeutet, dass die Sperrdatei respektiert wird, selbst wenn Versionen innerhalb der Sperrdatei mit Versionen in Konflikt stehen, die in package.json . Dies sollte in erster Linie nur auftreten, wenn ein Entwickler vergisst, seine yarn.lock einzuchecken, nachdem er Änderungen an den package.json .

Eine weitere Rolle eines Paketmanagers besteht darin, Projekten die Kontrolle über ihre Abhängigkeiten zu geben. Wenn es standardmäßig rein gemacht wird, können Entwickler einen Blick auf veraltete Garne werfen, um die veralteten Versionen zu sehen und dann die Änderungshinweise zu überprüfen, um brechende Änderungen zu vermeiden. Dies würde Entwicklern die volle Kontrolle geben, um nur Versionen in einem bestimmten Release-Zeitrahmen zu pushen, anstatt Entwicklern zu verbieten, git commit -a auszuführen, um versehentliche Lockfile-Commits zu vermeiden.

Wenn sich package.json nicht geändert hat, ist es meiner Meinung nach ein Fehler, wenn yarn.lock aktualisiert wird. Mindestens ein Fall des Fehlers scheint im Originalbericht enthalten zu sein:

lockfile wird je nach Umgebung (der derzeit installierten Garnversion) geändert.

Ich denke, das ist ein Fehler und sollte korrigiert werden.

Später im Thread sagte @thejameskyle :

Stellen Sie sich eine Memoize-Funktion vor, bei der die Eingabe eine package.json und die Ausgabe das Garn.lock ist.

Das ist meiner Meinung nach genau das richtige mentale Modell (" yarn.lock kann sich ändern, wenn und nur wenn sich package.json geändert hat"), und wenn die Abstraktion undicht wird, sollten wir es reparieren.

@adamchainz sagte:

Weitere Informationen zu oben: Unser Build hat Coffeescript von Github als Unterabhängigkeit. Coffeescript hat einige Commits gedrückt und wir haben eine modifizierte Garn.lock in unserem Build-Prozess erhalten, indem wir nur Garninstallation ausführen

und später:

Aber es hat das schlechte Verhalten, wenn eine Abhängigkeit von github installiert wird, wie ich oben berichtet habe

Das Problem dabei ist, dass Garn das Git-Sha nicht als Teil der gesperrten Version von Git-Abhängigkeiten behandelt. Cargo und Bundler haben beide das Konzept einer "präzisen" Version, die in die Lockfile serialisiert wird; für Git-Quellen ist die "genaue" Version der SHA. Wenn Sie dann einen neuen Klon mit nur package.json und yarn.lock erstellen und yarn ausführen, sind alle Informationen vorhanden, die Sie benötigen, um genau den Code zu erhalten, den Sie benötigen.

Ich muss gestehen, dass ich diese Interaktion bei der Überprüfung des ursprünglichen Git-Codes verpasst habe; Es gibt einige SHA-Tracking im Code, aber yarn install stellt nicht sicher, dass das hydratisierte Abhängigkeitsdiagramm dies respektiert.

TL;DR

Ich stimme @thejameskyle und @kittens zu, dass yarn.lock automatisch mit package.json synchronisiert werden sollte, weil ich glaube, dass Benutzer davon ausgehen können sollten, dass Versionen in ihren package.json richten sich nach dem, was verwendet wird, wenn ihre App ausgeführt wird.

Es scheint jedoch einige Fehler zu geben, die eine unangemessene Abwanderung in den yarn.lock selbst wenn sich die package.json nicht geändert haben:

• Änderungen an der Garnversion auf allen Maschinen aktualisiert die Lockfile
• git-Abhängigkeiten werden aktualisiert, auch wenn package.json nicht aktualisiert wurde, wodurch dann die Sperrdatei aktualisiert wird

Wir sollten auch etwas wie das --locked Flag von Cargo in Betracht ziehen, das Sie in CI verwenden können, um den Build schnell zu fehlschlagen, wenn ein Entwickler die package.json aktualisiert und vergisst, die aktualisierten yarn.lock einzuchecken.

@thejameskyle Danke! :heart: Ich stimme dir und @kittens zu, dass yarn.lock aktualisiert werden sollte, nachdem package.json geändert wurde

@wycats Wie immer ein sehr gründlicher und aufschlussreicher Beitrag. :+1: Ich stimme dir zu und ich mag auch die Idee eines --locked Flags (oder ähnlich). Dazu sollten wir eine neue Ausgabe erstellen.

#1568 erstellt, um das Git-SHA-Problem zu verfolgen

@wycats , danke für die entwirrende, sehr aufschlussreiche Übersicht!

Das bedeutet, dass wenn ein Repository zum ersten Mal auf einer Maschine geklont wird, wenn das Garn.lock eingecheckt wurde, es immer als die Quelle der Wahrheit behandeln sollte, keine Aktualisierungen für das Garn.lock generieren und direkt zum Abrufschritt springen sollte.
Soweit dies nicht das aktuelle Verhalten von Garn ist, halte ich das für einen Fehler.

Das ist genau das Szenario, warum dieses Thema geöffnet wurde.
Wir haben ein paar aktive Versionen von Yarn im Unternehmen und in unserer Größenordnung glaube ich nicht, dass wir überall atomare Updates machen können.
Baut auf Garn 0.13, 0.14 und 0.15 auf, führte zu leichten Variationen in den Garn.lock-Dateien, obwohl package.json synchron war.
Dies führte zu einigen Problemen, zum Beispiel wurden Buck-Builds verlangsamt, weil Änderungen im Quellbaum Caches ungültig machten.
Das hat mir und ein paar Teams ein paar Stunden Arbeit beschert.

@thejameskyle , danke, dass du deine Meinung
Ich habe das Szenario, dass package.json nicht mit Garn.lock synchron ist, nicht für fair gehalten. Und Sie haben einen gültigen Punkt.

Wie @wycats jedoch darauf hingewiesen hat, ist der ursprüngliche Fehlerbericht gültig.
Dies zu beheben ist wichtig, um gültige Builds zu haben, und ich werde das Problem erneut öffnen, um eine Lösung zu finden, die alle interessierten Parteien zufriedenstellt.

@wycats

Genauer gesagt sind die erwarteten Semantiken meiner Meinung nach:

• Wenn sich package.json seit der letzten Änderung von yarn.lock geändert hat, ist yarn.lock die Quelle der Wahrheit und sollte nicht aktualisiert werden.
• Wenn sich package.json seit dem letzten Mal geändert hat, yarn.lock geändert wurde, aktualisieren Sie yarn.lock so, dass es package.json erfüllt und aktualisieren Sie node_modules .
• Wenn yarn update wird, lösen Sie alle Abhängigkeiten erneut auf und holen Sie sich die neueste Version von allem, was die package.json erfüllt.

Das bedeutet, dass wenn ein Repository zum ersten Mal auf einer Maschine geklont wird und das yarn.lock eingecheckt wurde, es immer als die Quelle der Wahrheit behandelt werden sollte, und keine Updates für das yarn.lock generieren und springen direkt zum Abrufschritt.

Dies ist die Semantik, der wir folgen und die ich in #364 hinzugefügt habe.

@bestander Du warst an der PR (#364) beteiligt, die diese Heuristiken eingeführt hat. Welche zusätzlichen Änderungen schlagen Sie vor?

Dieses Problem ist sehr weit gefasst und wir haben uns bereits darauf geeinigt, dass --pure-lockfile nicht der Standard ist und wir folgen den von @wycats skizzierten Heuristiken. Wenn dieses Problem offen bleiben soll, muss der Titel das aktuelle Problem mit diesem Verhalten widerspiegeln.

@kittens klingt gut, ich werde das Problem aktualisieren.
Oder vielleicht sollte ich ein neues öffnen, das sich auf die Installation bezieht, die die Sperrdatei ändert, wenn sich package.json nicht geändert hat

Können wir zu einer neuen Ausgabe übergehen? Diese Kommentare hier können nur als Archiv aufbewahrt werden

Klingt gut, @thejameskyle , ich erstelle heute eine neue Ausgabe und verlinke hier

Erstellt die neue fokussierte Ausgabe https://github.com/yarnpkg/yarn/issues/1576

Es wäre interessant, eine Option zu haben, um yarn install Scheitern zu bringen, wenn das Paket in package.json nicht in Garn.lock ist, dh. fehlschlagen, wenn ein Paket nicht gesperrt ist

Hinzufügen einer Klarstellung, die mir nach dem Lesen des Obigen immer noch mehrdeutig war:

TLDR; Unabhängige Änderungen in package.json aktualisieren ein Paket nicht auf die neueste Version, die mit seinem unveränderten package.json Server kompatibel ist.

Basierend auf einigen der obigen Formulierungen klang es so, als ob yarn.lock auf einem package.json Hash zwischengespeichert wurde, und somit klang es yarn.lock geschrieben (aktualisiert / Cache ungültig gemacht) ) auf jede Änderung package.json , die seit einem nicht verwandten Änderung (dh Update problematisch sein würde "description" oder eine andere Abhängigkeit) , die Abhängigkeit der kann dazu führen , yarn.lock Version aktualisiert werden eine neuere Version innerhalb desselben existierenden package.json Semvers.

Ich habe jedoch überprüft, dass der Eintrag yarn.lock eines Pakets nur geschrieben wird, wenn der entsprechende package.json Semver aktualisiert wird (auch wenn der neue Semver mit der vorhandenen yarn.lock Version kompatibel ist, und folglich sonst kein Versionsupdate erforderlich machen würde).

Zum Beispiel,

• Sagen wir yarn add lodash@^4.17.1 installiert [email protected]
• Später ist [email protected] verfügbar.
• Garn wird weiterhin [email protected] installieren
• Es sei denn/bis die Version von lodash in package.json geändert wird (oder das Hinzufügen/Aktualisieren/Entfernen von Garn wird speziell gegen lodash ausgeführt).

Semmelbrösel #1576

Übrigens, wenn Sie bereit sind, mit kleinen Artikeln wie diesem zur Dokumentation beizutragen, wäre dies großartig für die Community.
Das Kernteam ist damit beschäftigt, Probleme zu beheben und neue Funktionen hinzuzufügen, und es wird erwartet und geschätzt, wenn die Community dabei hilft, die Dokumentation aufrechtzuerhalten

@CrabDude danke für das Teilen deiner Klarstellung.

Meinen Sie - in Ihrem obigen Beispiel -, dass nur lodash und seine eigenen Abhängigkeiten ihre Sperrversionen in yarn.lock aktualisiert haben? zB selbst wenn eine andere Abhängigkeit eine neue Sperrversion haben könnte , wird sie dann nicht gleichzeitig aktualisiert?

Oder ein zweites Beispiel: Nehmen wir an, ein yarn.lock ist stark veraltet und der Benutzer führt yarn add , um eine neue Abhängigkeit zu package.json hinzuzufügen. Werden alle anderen veralteten Pakete jetzt in yarn.lock aktualisiert oder bleiben sie gleich?

@rarkins

Meinen Sie - in Ihrem obigen Beispiel -, dass nur die Lock-Versionen von Lodash und seinen eigenen Abhängigkeiten in Garn.lock aktualisiert werden?

Jawohl. Dies scheint in meinem Beispiel bestätigt zu werden.

Werden jetzt alle anderen veralteten Pakete in Garn.lock aktualisiert oder bleiben sie gleich?

Es scheint, dass die Nicht- lodash Abhängigkeitsbäume / Sperreinträge von Paketen nicht aktualisiert würden; nur die lodash wären.

Beides ist aus meiner Sicht sowohl wünschenswert als auch erwartet.

Vorwort : Ich liebe Garn. Aber es frustriert mich ohne Ende.

In meiner Firma ändert yarn install die Sperrdatei ständig auf verschiedenen Computern (auf denen jeweils dieselbe Version ausgeführt wird), obwohl package.json nie geändert wird. Und wenn wir das tun, aktualisieren wir mit yarn add . Dies ist ärgerlich, da CI nach einem Build überprüft, ob der Git-Status sauber ist, um sicherzustellen, dass wir nicht vergessen haben, Dinge wie das Einchecken einer Sperrdatei zu tun, und er ändert sich häufig.

Meine Erwartung von Garn war, dass es _standardmäßig_ identische node_modules auf allen Maschinen sicherstellt. Nicht mit zusätzlichen Flaggen. Es würde der Korrektheit Vorrang vor der Bequemlichkeit geben. Wenn ich Unsicherheit wollte, konnte ich npm direkt verwenden. Wenn sich eine Datei ändert, ist das für mich ein Signal, dass sich etwas daran geändert hat und ich sie genau prüfen sollte. Es sollte sich nicht ändern.

Fragen

• Soll gesagt werden, dass trotz der Änderung der Lockfile der Inhalt von node_modules immer identisch ist mit dem, als er generiert wurde? Ich glaube nicht, dass dies der Fall ist, aber wenn es so ist, verstehe ich die Verwirrung in diesem Thread - es würde bedeuten, dass Garn das Richtige tut, obwohl es scheinbar nicht so ist.
• Wenn sich package.json ändert, wird die Sperrdatei neu generiert. Könnte das nicht unbeabsichtigt viele Abhängigkeiten ändern, abhängig vom Zustand der node_modules dieses bestimmten Programmierers? Yarn sollte ein Delta bestimmen und versuchen, vorhandene Sperren so gut wie möglich zu erhalten (falls dies noch nicht geschehen ist).
• Warum gibt yarn add Versionen in package.json mit einem ^ ? Auch hier verstand ich, dass das Versprechen von Garn darin bestand, Abhängigkeiten einzufrieren.

Verwandte Fehler

• Wenn ein zufälliges Paket in node_modules gelöscht wird, sagt yarn install Erfolg, ohne es neu zu installieren. Wenn viele von ihnen weg sind, werden sie neu installiert. npm ist diesbezüglich etwas gründlicher.
• Die Lockfile neigt dazu, neu generiert zu werden, wenn Sie node_modules löschen und eine saubere Installation durchführen (was buchstäblich das Gegenteil von dem ist, was Sie erwarten würden - ich erwarte, dass es genau das installiert, was in der Lockfile steht und absolut nichts anderes tut).
• Wenn Sie die Sperrdatei löschen, ohne das Paket oder node_modules nach einer Neuinstallation zu berühren, regeneriert Garn sie und unterscheidet sich normalerweise stark von der vorherigen Version. Dies ist wie ein Compiler, der jedes Mal, wenn Sie ihn ausführen, unterschiedlichen Code erzeugt, obwohl er nichts geändert hat.

Insgesamt macht Garn die Installationen schneller, scheint aber an seiner (Un-)Kompetenz zu scheitern: Versionen standardmäßig konstant einzufrieren. Ich brauche keine Annehmlichkeiten, die mir helfen, mein Projekt zu starten, ich brauche Hilfe, um es über viele Jahre hinweg in einem riesigen Team aufrechtzuerhalten. Programmierer sind klug und absichtlich, wenn sie eine Änderung wünschen, werden sie explizit fragen.

Die sich ständig ändernde Lockfile flößt kein Vertrauen ein und ist ein ständiger Ärger. Ich bevorzuge Warnungen und Fehler, dass package.json nicht mit der Sperrdatei übereinstimmt, dass die Sperrdatei nicht mit node_modules übereinstimmt, dass eine gesperrte Version nicht mehr existiert usw bewusste Entscheidungen über meine Abhängigkeiten treffen.

@jspiro , danke für das Aufschreiben.
Hier werden einige Probleme angesprochen.
Es wäre besser, jede Ausgabe separat zu öffnen, sonst gehen sie in den Kommentaren verloren.

Verwenden Sie die neueste Version von Yarn?
Ab 0.18-0.19 sehen wir keine Änderungen an den Garn.lock-Dateien zwischen den Maschinen.

Fragen:

Soll gesagt werden, dass trotz der Änderung der Lockfile der Inhalt von node_modules immer identisch ist mit dem, als er generiert wurde? Ich glaube nicht, dass dies der Fall ist, aber wenn es so ist, verstehe ich die Verwirrung in diesem Thread - es würde bedeuten, dass Garn das Richtige tut, obwohl es scheinbar nicht so ist.

Dev- und optionale Abhängigkeiten können für dieselbe Lockfile weggelassen werden.
Aber diejenigen, die bing installiert sind, mit Ausnahme von plattformspezifischen Paketen, node_modules sollten identische Pakete an identischen Stellen haben.

Wenn sich package.json ändert, wird die Sperrdatei neu generiert. Könnte das nicht unbeabsichtigt viele Abhängigkeiten ändern, abhängig vom Zustand der node_modules dieses bestimmten Programmierers? Yarn sollte ein Delta bestimmen und versuchen, vorhandene Sperren so gut wie möglich zu erhalten (falls dies noch nicht geschehen ist).

Das ist eine nette Feature-Anfrage, würde gerne eine PR dafür sehen.

Warum fügt Garn Versionen in package.json mit einem ^ hinzu? Auch hier verstand ich, dass das Versprechen von Garn darin bestand, Abhängigkeiten einzufrieren.

Das spiegelt das Verhalten von npm wider.
Sie können yarn add [email protected] oder yarn add is-array --exact für die genaue Version ausführen.
Vielleicht sollten wir irgendwann die genauen Versionen als Standard festlegen, dies kann eine Diskussion in einem RFC sein.

Wenn ein zufälliges Paket in node_modules gelöscht wird, sagt Garninstallation Erfolg, ohne es neu zu installieren. Wenn viele von ihnen weg sind, werden sie neu installiert. npm ist diesbezüglich etwas gründlicher.

Yarn führt standardmäßig eine schnelle flache Prüfung durch.
Eine eingehendere Überprüfung wird langsamer sein, aber wir arbeiten daran, ich habe eine Idee, wie wir eine schnelle eingehende Überprüfung durchführen könnten.
Sie sollten jedoch keine Dateien in node_modules berühren, da die Überprüfung jeder Datei auf Änderungen zu einer sehr langsamen Installation führen würde.
Wenn Sie die flache Prüfung überspringen möchten, entfernen Sie die Datei node_modules/.yarn-integrity vor der Installation. Dies ist nicht offiziell und kann sich ändern.
Ein offizieller Weg ist yarn install --force auszuführen, es würde eine vollständige Installation erzwingen, aber als Nebeneffekt würde es "garn.lock" neu schreiben.

Die Lockfile neigt dazu, neu generiert zu werden, wenn Sie node_modules löschen und eine saubere Installation durchführen (was buchstäblich das Gegenteil von dem ist, was Sie erwarten würden - ich erwarte, dass es genau das installiert, was in der Lockfile steht und absolut nichts anderes tut).

Habe das schon länger nicht mehr gesehen.
Öffnen Sie ein Problem und schreiben Sie mir, wenn dies reproduziert werden kann.

Wenn Sie die Sperrdatei nach einer Neuinstallation löschen, ohne Package oder node_modules zu berühren, regeneriert Garn sie und unterscheidet sich normalerweise stark von der vorherigen Version. Dies ist wie ein Compiler, der jedes Mal, wenn Sie ihn ausführen, unterschiedlichen Code erzeugt, obwohl er nichts geändert hat.

Nach einiger Zeit werden möglicherweise neue Versionen von transitiven Abhängigkeiten veröffentlicht.
Aus diesem Grund kann sich die Struktur von node_modules aufgrund der Hublogik erheblich ändern.
Das funktioniert wie geplant.
Es gibt den Befehl import https://github.com/yarnpkg/yarn/pull/2580.
Dadurch können Sie eine Sperrdatei aus vorhandenen node_modules generieren.

@jspiro , Yarn ist ein junges Community-getriebenes Projekt, Ihre PRs, damit es für Sie besser funktioniert, sind willkommen.

Gibt es eine Chance, zumindest eine Option zum Festlegen des gewünschten Standardverhaltens zu erhalten?

Derzeit beheben wir dieses Problem https://github.com/yarnpkg/yarn/issues/3490 , manchmal kann yarn install dazu führen, dass die Lockfile optimiert wird, was nicht erwartet wird, und wir werden es beheben.
Dies könnte der Grund sein, warum Sie diese Änderung verlangen, ansonsten sollte sich die Datei "Garn.lock" nur ändern, wenn Sie manuell Änderungen an package.json vornehmen.

Sie können --pure-lockfile/--frozen-lockfile in .yarnrc auf true setzen und es wird standardmäßig an den Installationsbefehl angehängt:

--install.pure-lockfile true

Mein Problem ist, dass ich die falsche Version der Abhängigkeiten installiert bekomme, wenn ich pure-lockfile nicht verwende. Es hat nichts mit den unerwünschten Garn.lock-Änderungen zu tun

Können Sie ein Problem mit Repro-Schritten einreichen?
Wir klären das

Ich war auch davon gebissen, als package.json und yarn.lock nicht mehr synchron waren, weil ein Entwickler irrtümlicherweise eine Abhängigkeit über npm install --save anstelle von yarn add hinzugefügt hatte.

Ich bin jedoch anderer Meinung, dass pure-lockfile der Standardwert sein sollte und argumentiere, dass eher frozen-lockfile der Standardwert für yarn install .

Da frozen-lockfile eine Fehlermeldung liefert, wenn yarn.lock und package.json nicht synchron sind. Das frozen-lockfile ist daher auf einer Build-Maschine (zB Jenkins) sehr hilfreich, da es diese Builds erwartungsgemäß als fehlgeschlagen markiert.

Es liegt dann am Entwickler, zu entscheiden, welche Version in package.json /garn.lock hinzugefügt werden soll.

Die unglückliche Vorgabe von yarn install holt nur die aktuellste Version der noch nicht in Abhängigkeiten gesperrten und schreibt eine aktualisierte Version yarn.lock , die nie Teil des Projekts sein wird. Dies ermöglicht zukünftige Unterbrechungen des Builds aufgrund eines unerwarteten Versionssprungs. Das ist der Grund, warum wir zunächst eine Lockfile haben.

Das Wesentliche sollte jedoch sein:

Nur Befehle wie add , remove und upgrade sollten yarn.lock mutieren.

install sollte genau das tun, nämlich entweder die Abhängigkeiten in ihrer gesperrten Version installieren oder fehlschlagen, wenn es eine Diskrepanz zwischen package.json und yarn.lock erkennt. (Die einzige Ausnahme besteht darin, dass es überhaupt kein yarn.lock . Dann, und nur dann, kann es eines erstellen, aber es sollte es nie wieder berühren.)

Das Frozen-Lockfile ist daher auf Build-Maschinen (zB Jenkins) sehr hilfreich, da diese Builds fehlschlagen.

Ich denke, wir können dies automatisch aktivieren, wenn wir feststellen, dass wir uns im CI-Modus befinden?

@BYK Ich wusste nicht, dass dieses Problem geschlossen wurde, bevor ich es hier hinzugefügt habe. Soll ich vielleicht einen neuen eröffnen oder kann dieser wieder geöffnet werden?

Ich würde sagen, mach ein neues auf ☺️

Ich stimme @thejameskyle und @kittens zu, dass Garn.lock automatisch mit package.json synchronisiert werden soll

Ich bin mir nicht sicher, ob dies gesagt wurde, aber nur für den Fall: Sie müssen nicht die gesamte Garn.lock ungültig machen, wenn sich etwas in package.json ändert. Sie können nur die Abhängigkeiten von nur Paketen ungültig machen, die innerhalb von package.json geändert wurden. Wenn Sie beispielsweise nur TypeScript aktualisiert haben, müssen die Abhängigkeiten von TypeScript geändert werden (unter Berücksichtigung anderer unveränderter Pakete).