Ich denke nicht, dass dies ein Fehler ist. Ich konnte das Problem reproduzieren, aber der Unterschied war

52,55d51
< ansi-regex@*:
<   version "3.0.0"
<   resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-3.0.0.tgz#ed0317c322064f79466c02966bddb605ab37d998"
<
1352c1348
< imurmurhash@*, imurmurhash@^0.1.4:
---
> imurmurhash@^0.1.4:

Diese Änderung ist nur eine Optimierung der Sperrdatei und ändert nichts an der Semantik. Wir planen, eine Warnung hinzuzufügen, wenn die Sperrdatei aktualisiert werden muss, wenn yarn install Wenn Sie jedoch sicherstellen möchten, dass Ihre Sperrdatei gleich bleibt und korrekt ist, sollten Sie die Option --frozen-lockfile .

Ich muss zugeben, dass dies etwas unintuitiv ist und wir versuchen, eine gute Lösung dafür zu finden. Sie können der Diskussion auf # 4147 folgen oder dazu beitragen.

Wenn Sie damit einverstanden sind, dass dies kein Fehler ist und # 4147 ein guter Ort ist, um die Diskussion fortzusetzen, schließen Sie bitte das Problem :)

@ BYK danke für deine nachdenkliche Antwort. Nachdem ich # 4147 gelesen habe, bin ich am Zaun, um dieses Problem zu schließen. Ich hoffe, dass ein bisschen mehr Diskussion hier helfen kann.

4147 scheint sich ausschließlich mit dem Fall zu befassen, in dem yarn.lock und package.json nicht synchron sind. Die einzige Zeitoptimierung wird in diesem Kommentar erwähnt: https://github.com/yarnpkg/yarn/issues/4147 #issuecomment -321894341 - und dieser Kommentar berührt das Problem, das mich betrifft: Garn, das die yarn.lock -Datei ändert, wenn keine Änderungen an package.json .

Es scheint mir, dass sich die yarn.lock -Datei nur ändern sollte, wenn sich meine Abhängigkeiten irgendwie ändern. Tatsächlich habe ich meinen Entwicklern bis zu diesem Punkt gesagt, dass es Zeit ist, yarn install auszuführen, wenn sie eine Änderung in der yarn.lock -Datei sehen. Bei den letzten Upgrades haben mehrere zurückgemeldet, dass sich ihre Sperrdatei geändert hat, nachdem sie meine Änderungen erhalten und yarn install haben (die Optimierung). Dies führt zu einer verwirrenden Situation - sollten sie die Änderung begehen? Sollte ich die Sperrdatei irgendwie voroptimieren (ist das überhaupt möglich)?

Es sieht so aus, als müsste ich kurzfristig in all meinen Repos --frozen-lockfile true zu .yarnrc hinzufügen - aber ich bin kein großer Fan dieser Lösung, da dies den in erwähnten Workflow ausschließt # 4147 wo Sie die package.json bearbeiten und dann yarn install ausführen.

Ist die Absicht, dass ein Aufruf von Garn yarn.lock ändern könnte?

@BYK Es tut mir leid, Sie darüber zu stören, weil ich weiß, dass Sie sehr beschäftigt sind - aber ich hoffe, eine endgültige Antwort darauf zu bekommen. Mein Workflow zum Verteilen von Abhängigkeitsänderungen an mein Team hat sich folgendermaßen entwickelt:

yarn add [blah]
rm -r node_modules yarn.lock
yarn install
rm -r node_modules
yarn install

Dies scheint die Sperrdatei ordnungsgemäß zu aktualisieren (siehe # 4476) und dann die Sperrdatei so zu optimieren, dass meine Teamkollegen keine Änderungen an der Sperrdatei einchecken.

Verwendet mein Team Garn falsch? Sollten wir erwarten, dass sich die Sperrdatei mit jedem Befehl install ändert?

@artlogic IMHO sollten Ihre Teamkollegen die Möglichkeit haben, Änderungen an Sperrdateien einzuchecken, auch wenn es sich nur um Optimierungen handelt. Ich stimme der Vorstellung zu, dass die Optimierung der Sperrdatei durch yarn install nicht intuitiv ist, aber dennoch von jedem Entwickler Ihres Teams sicher festgelegt werden kann. Ich verstehe nicht, warum Sie das verbieten wollen.

Abgesehen davon kann Ihr Workflow zu unerwarteten Nebenwirkungen führen, da Sie die gesperrten Versionen so gut wie aufgeben. Das Löschen der Sperrdatei bedeutet, dass das Garn alle Abhängigkeitsversionen erneut auflösen muss, und es wird versucht, die aktuellste Version abzurufen, wie in Ihrem package.json was zu einem möglichen Bruch führen kann, insb. wenn in einer zukünftigen Version mehr als eine Abhängigkeit gleichzeitig unterbrochen wird.

Wenn Sie dennoch erzwingen möchten, dass die Installation die Sperrdatei nicht berührt, sollten Sie das Flag frozen-lockfile verwenden:

 yarn add {blah}

Checken Sie die Sperrdatei ein, und dann würde ein anderer Entwickler Folgendes verwenden:

   yarn install --frozen-lockfile

Fügen Sie NICHT --frozen-lockfile zu true in .yarnrc da dies verhindert, dass Sie jemals aktualisieren, siehe: # 4570

Wenn Sie Ihre Abhängigkeiten aktualisieren möchten, führen Sie Folgendes aus:

 yarn upgrade

Wenn Sie nur eine Abhängigkeit aktualisieren möchten:

  yarn upgrade {blah}

Sie können auch einfach eine bestimmte Version einer Abhängigkeit installieren:

  yarn install {blah}@1.5

Dies ermöglicht auf lange Sicht mehr Feinabstimmung und weniger Kopfschmerzen.

@ k0pernikus - danke für deine ausführliche Antwort. Zunächst sollte ich mich dafür entschuldigen, dass zwei Probleme zusammengeführt wurden - # 4476 steuert einen Teil meines Workflows. Die Tatsache, dass yarn upgrade etwas kaputt zu sein scheint, hat natürlich nichts mit diesem Problem zu tun.

Was den Workflow betrifft, kann ich mir nicht vorstellen, dass mein Team das einzige ist, in dem ein Entwickler für das Verwalten / Testen neuer Abhängigkeiten verantwortlich ist, während die anderen Entwickler an der Codebasis arbeiten. Das große Problem, das ich mit dem, was begonnen hat, habe, ist, dass ich neue Abhängigkeiten installiere / teste, jedem sage, er solle yarn install ausführen und dann 4-5 Fragen dazu bekommen, ob die geänderten yarn.lock festgeschrieben werden sollen . Es scheint, als wäre ich an einem schlechteren Ort, wenn ich sagen würde "Wenn sich die Sperrdatei ändert, schreiben Sie sie fest", weil ich an diesem Punkt eine Festschreibungssperre erhalten könnte, die ungefähr so ​​aussieht:

• yarn.lock geändert (dev4)
• yarn.lock geändert (dev3)
• yarn.lock geändert (dev2)
• yarn.lock geändert (dev1)
• Aktualisierte Abhängigkeiten (ich)

Es könnte jedoch sein, dass dies genau die Art und Weise ist, wie Garn funktionieren soll. Daher werden wir für die Projekte meines Teams alle unsere Repos so ändern, dass gefrorene Sperrdateien verwendet werden, sodass nur add und upgrade verursachen Sperrdatei zum Ändern.

Ein zusätzliches Szenario ... es scheint, dass dies ein potenzielles Ärgernis für Projekte mit vielen Mitwirkenden sein könnte, da sich die Sperrdatei möglicherweise jedes Mal ändert, wenn sie klonen und installieren. Ich würde diese Optimierungen sicherlich nicht in Pull-Anfragen wollen. Ist die Absicht, dass die meisten FOSS-Projekte den Garnübergang auch in eine gefrorene Sperrdatei umwandeln?

@artlogic Unser Team hat aus genau diesem Grund --install.pure-lockfile true im .yarnrc des Projekts.

@jboler - Ich hatte diese Einstellung noch nie gesehen. Ich werde einen Blick darauf werfen müssen, aber es sieht so aus, als würde ich vorschlagen, dass wir das zu den .yarnrc für alle unsere Repos und alle Repos aller FOSS-Projekte hinzufügen, die ich habe.

Wenn jemand aus dem Garnteam bestätigen kann, dass yarn install die Sperrdatei bei jedem Lauf ändern kann und wird (trotz keiner Änderung der Abhängigkeiten), werde ich dieses Problem schließen.

@artlogic Entschuldigung für die späte Antwort.

Die Sache ist, es ist __erwartet__, dass yarn install möglicherweise die Sperrdatei ändert. Ich weiß, dass dies nicht ideal ist und eine bessere Kommunikation benötigt. Ich möchte wirklich eine bessere Standardeinstellung haben, aber in der Zwischenzeit denke ich, dass etwas wie @jboler mit --frozen-lockfile vorgeschlagen wurde, aber vielleicht die beste Lösung wäre, bis wir herausgefunden haben, wie sich Garn unter verschiedenen Szenarien wie z Workflows, in denen Benutzer lieber einfach package.json bearbeiten, um Abhängigkeiten zu aktualisieren, anstatt yarn add usw. zu verwenden.

@BYK Ich stimmte @artlogic zu . Dieses Verhalten ist sehr verwirrend:

Das große Problem, das ich mit dem, was begonnen hat, habe, ist, dass ich neue Abhängigkeiten installiere / teste, jedem sage, dass er die Garninstallation ausführen soll, und dann 4-5 Fragen dazu bekomme, ob das geänderte Garn.lock festgeschrieben werden soll.

Unser Team besteht aus ~ 50 Personen, die jeden Tag yarn install ausführen :(

@vkrol Sie sollten in der Lage sein, eine .yarnrc -Datei mit --install.frozen-lockfile true oder --install.pure-lockfile true einzuchecken, um Probleme zu vermeiden, bis Yarn sein Verhalten ändert. Würde das helfen?

@BYK pure-lockfile wird uns helfen, aber nicht frozen-lockfile . Wenn ich das richtig verstehe, schlägt yarn install mit einem Fehler fehl, wenn Frozen-Lockfile aktiviert ist. Dieses Verhalten ist in unserem Fall absolut inakzeptabel.

@vkrol Meine Präferenz ist frozen-lockfile da es nur fehlschlägt, wenn Ihre Sperrdatei geändert werden muss und nicht konsistent ist. Mit pure-lockfile Sie möglicherweise eine Sperrdatei, die fast unbrauchbar oder sehr ungenau ist, aber Sie würden trotzdem keinen Fehler bekommen. Garn würde einfach die internen Auflösungen verwenden, die es glücklich berechnet. Wenn alle Ihre Teammitglieder genau dieselbe Version von Yarn verwenden, sollte dies in Ordnung sein. Wenn nicht, kann es gefährlich sein.

@BYK Vielleicht verstehe ich das Verhalten von frozen-lockfile richtig. Schlägt es fehl, wenn die Sperrdatei mit dem Inhalt von package.json übereinstimmt, aber eine interne Optimierung erforderlich ist?

@vkrol Es sollte nicht fehlschlagen, wenn die Datei weiter optimiert werden kann, aber es ist konsistent mit package.json und an sich konsistent. Wenn nicht, ist dies ein Fehler. Hierfür gibt es sogar einen Test: https://github.com/yarnpkg/yarn/blob/0415b07b3293ab125a77f3f66fe14034d6e5b376/__tests__/commands/install/lockfiles.js#L72 -L84

@ BYK Ich wusste es nicht. Ich werde diese Option ausprobieren, danke! Ich denke, dass diese Tatsache irgendwo dokumentiert werden sollte.

@ BYK

Es sollte nicht fehlschlagen, wenn die Datei weiter optimiert werden kann, aber es ist konsistent mit package.json und an sich konsistent.

Ich habe einen Nachteil bei der Verwendung dieser Flagge festgestellt. Wenn yarn.lock optimiert werden kann, werden die wiederholten Aufrufe dieses Befehls yarn install --frozen-lockfile nicht wie ohne dieses Flag über die Integritätsprüfung optimiert. Ist das ein Fehler? Muss ich das separate Problem erstellen?

@ BYK Danke für deine Antwort. Für die Projekte meines Teams verwenden wir jetzt frozen-lockfile und die Dinge funktionieren (relativ) gut. Dieses Problem ist für mich jedoch weiterhin von großer Bedeutung. Insbesondere die unnötigen Optimierungen, die Garn an der Sperrdatei vornimmt, wenn yarn install .

Hier ist das klarste Beispiel, das ich geben kann, wo dieses Verhalten Probleme verursacht:

1. Ich füge eine neue Abhängigkeit mit yarn add [blah] und lege meine aktualisierten package.json und yarn.lock .
2. Mitwirkende an meinem Paket ziehen Änderungen herunter und stellen fest, dass yarn.lock aktualisiert wurde, und führen daher ein yarn install .
3. In einigen Fällen erhalten diese Mitwirkenden nach der Installation ein modifiziertes yarn.lock . Was sollen sie in diesem Fall tun? Ist es ein Rennen, um zu sehen, wer zuerst die Pull-Anfrage einreichen kann?

Um klar zu sein, ich habe kein Problem damit, yarn install yarn.lock wenn package.json geändert wurde. Mein Problem ist die Optimierung, wenn package.json nicht geändert wurde. Ich sehe drei mögliche Lösungen:

1. Richten Sie jedes Projekt, das Abhängigkeiten zentral verwaltet, so ein, dass einer Datei .yarnrc --install.frozen-lockfile true hinzugefügt wird. Dies wäre wahrscheinlich eine Menge Projekte - die meisten NPM-Pakete würde ich vermuten.
2. Stellen Sie einen Schalter bereit, um das Garn zu zwingen, die Sperrdatei während der Additionsphase zu optimieren, z. B. yarn add --optimize [blah] . Weisen Sie dann die Paketbetreuer an, diesen Schalter immer zu verwenden.
3. Verbieten Sie dem Garn die Optimierung von yarn.lock während der Installationsphase, es sei denn, package.json scheint aktualisiert worden zu sein.

Ich befürworte Option 3, aber ich könnte auch sehen, dass Option 2 eine vernünftige Wahl ist.

Vielen Dank für Ihre Zeit!

Ich mag die Idee, dass yarn install die yarn.lock -Datei nicht aktualisiert, sondern stattdessen eine Warnung ausgibt, dass "Ihre yarn.lock-Datei veraltet ist, führen Sie yarn blah bis aus aktualisiere es jetzt`.

@BYK warum ~ nicht ~ wendet Garn Optimierungen auf yarn.lock auf yarn install anstatt wenn add / upgrade werden?

bearbeiten: Tippfehler beheben

@ spencer-brown: Basierend auf dem, was ich gesehen habe, werden bei der Installation tatsächlich Optimierungen angewendet - das finde ich problematisch

Sollte die Optimierung auf yarn.lock nicht auf Garnzugabe ausgeführt werden? yarn.lock wird sich sowieso ändern. Dies ist Option Nummer zwei in @artlogics jüngstem Kommentar, richtig? Warum erfolgt die Optimierung dann nicht, sodass niemand anderes eine weitere Änderung des Garns vornehmen muss?

@artlogic oops, Tippfehler :) - mein Kommentar sollte "tut" sagen; bearbeitet.

Wir verwenden häufig Komponisten und composer install berührt die Sperrdatei nie.

composer update oder composer require (entspricht yarn add ) muss ausgeführt werden, damit Änderungen oder Optimierungen an der Sperrdatei vorgenommen werden können.

In vielen Jahren mussten wir uns nie um ein mehrdeutiges Verhalten von composer install sorgen.

Mir ist klar, dass Garn eine etwas andere Rolle spielt, aber der Komponist hat das gleiche Problem, dass manuelle Aktualisierungen auf composer.json und nicht mehr mit der Sperrdatei synchronisiert sind. Derzeit composer install wird vollständig ignorieren composer.json Datei und eine Warnung ausgeben.

Wir verwenden häufig Komponisten und composer install berührt die Sperrdatei nie.

composer update oder composer require (entspricht yarn add ) muss ausgeführt werden, damit Änderungen oder Optimierungen an der Sperrdatei vorgenommen werden können.

In vielen Jahren mussten wir uns nie um ein mehrdeutiges Verhalten von composer install sorgen.

Mir ist klar, dass Garn eine etwas andere Rolle spielt, aber der Komponist hat das gleiche Problem, dass manuelle Aktualisierungen auf composer.json und nicht mehr mit der Sperrdatei synchronisiert sind. Derzeit composer install wird vollständig ignorieren composer.json Datei und eine Warnung ausgeben.

Hey Kinder, die Sperrdatei sollte sich bei nachfolgenden Installationen niemals ändern. es ist nur dumm. Wenn Sie der Meinung sind, dass es sich lohnt, die Optimierung zu berühren, erstellen Sie stattdessen einfach eine separate Datei, die nicht in die Versionskontrolle einbezogen wird.

Wie bei Bundlers Gemfile.lock besteht der springende Punkt bei yarn.lock darin, dass Sie bei jeder Garninstallation deterministische Ergebnisse in allen Umgebungen garantieren können. Wenn die Garninstallation die Sperrdatei ändert, verlieren Sie diese Garantie. Andere Befehle wie das Hinzufügen von Garn oder das Aktualisieren von Garn sollten natürlich die Garnverriegelung ändern, die Garninstallation jedoch nicht. Unser Team ist auf Probleme gestoßen, bei denen leicht unterschiedliche Paketversionen in unterschiedlichen Umgebungen installiert sind, was genau das ist, was wir nicht wollen.

Ich bin geneigt zu denken, dass yarn install --pure-lockfile die Standardeinstellung sein sollte, und es könnte eine Option --fix-my-dev-process-inconsistencies-for-me-magically , um das aktuelle Verhalten zu erhalten.

@ryancastle --pure-lockfile sagt Ihnen nicht, dass ein Update für Ihre Sperrdatei ist. Es wird nur keine generiert. Dies kann immer noch zu unerwartetem Verhalten führen. --frozen-lockfile schlägt fehl, wenn ein Update erforderlich ist.

Ich arbeite seit einer Weile mit --install.frozen-lockfile true in meinem .yarnrc und es scheint auf vernünftige Weise zu funktionieren. Der Trick besteht darin, das anfängliche yarn.lock für das Repo zu erstellen, ohne dass dieses Flag wirksam ist. Einmal erstellt, können Installationen die yarn.lock nicht mehr ändern, Updates jedoch. Sobald ich diesen Workflow verwendet habe, ist die Anzahl der versehentlichen Änderungen an yarn.lock auf Null gesunken.

@artlogic Nebenbemerkung: Früher hatte ich auch frozen-lockfile true in meinem .yarnrc , jetzt erzwinge ich es nur auf dem Build-Server, da wir auf Probleme stießen, die absichtliche Änderungen an yarn.lock wurden nicht erstellt, z. B. beim Versuch, ein geändertes package.json mit dem yarn.lock zu synchronisieren, da ein Entwickler die package.json manuell bearbeitet oder npm zum Hinzufügen von Abhängigkeiten verwendet hat.

Siehe: https://github.com/yarnpkg/yarn/issues/4570

@ k0pernikus 'ist Anwendungsfall , warum wir nicht gemacht haben --frozen-lockfile den Standard mit yarn install . Ich weiß ehrlich gesagt nicht, was ein guter Kompromiss wäre, ohne Leute zu behindern, die package.json bearbeiten und dann yarn install ausführen, um die Sperrdatei zu aktualisieren. Ich habe ein Flag oder einen neuen Befehl wie yarn sync aber die Idee muss konkretisiert und dann von der Community beurteilt werden, bevor sie implementiert wird.

Darüber hinaus wäre dies eine bahnbrechende Änderung, sodass Yarn 2.x erforderlich wäre :)

eine Flagge oder ein neuer Befehl wie Garnsynchronisation

hört sich gut an 👍. und yarn install könnten einen Hinweis anzeigen "package.json und yarn.lock sind nicht synchron. Führen Sie 'yarn sync' aus, um die Sperrdatei zu aktualisieren."

Ich weiß ehrlich gesagt nicht, was ein guter Kompromiss wäre, ohne die Leute zu behindern, die package.json bearbeiten und dann die Garninstallation ausführen, um die Sperrdatei zu aktualisieren.

Ich denke, an einem bestimmten Punkt muss eine Entscheidung getroffen werden, wie der geeignete Arbeitsablauf aussehen soll. Dies zu aktivieren scheint mir fast wie ein Anti-Muster zu fördern.

Ich habe eine Flagge oder einen neuen Befehl wie Garnsynchronisierung vorgeschlagen, aber die Idee muss konkretisiert und dann von der Community beurteilt werden, bevor sie umgesetzt wird.

Für mich scheint dies ein vernünftiger Kompromiss zu sein. Wenn Sie darauf bestehen, Ihre package.json manuell zu bearbeiten, ist es sinnvoll, einen Befehl auszuführen, um die Dinge wieder synchron zu machen.

Folgendes würde ich gerne sehen:

• yarn install ohne yarn.lock erzeugt die yarn.lock .
• yarn install mit einem yarn.lock ändert es nicht. Wenn eine Diskrepanz zwischen yarn.lock und package.json festgestellt wird , wird ein Fehler zurückgegeben (wie bei
• yarn sync (oder vielleicht yarn install -s ) synchronisiert yarn.lock wieder mit package.json .

Ich habe immer noch Bedenken, dass yarn install die yarn.lock yarn install ändert, selbst wenn package.json nicht nicht mit der Sperrdatei synchronisiert ist. Sie werden oben sehen, dass einige "Optimierungen" durchgeführt werden. Wäre es möglich, dieses Verhalten zumindest zu deaktivieren, ohne eine Änderung vorzunehmen?

Ich habe immer noch Bedenken, dass die Garninstallation die Datei yarn.lock ändert, auch wenn package.json nicht nicht mit der Sperrdatei synchronisiert ist. Sie werden oben sehen, dass einige "Optimierungen" durchgeführt werden. Wäre es möglich, dieses Verhalten zumindest zu deaktivieren, ohne eine Änderung vorzunehmen?

Gleiches Gefühl hier. Ich dachte, dies sei der spezifische Grund dafür, dass dieses Problem offen bleibt. Da die "Synchronisation" in # 4147 diskutiert wird

Deshalb habe ich zuerst nach diesem Problem gesucht.

Sollen wir dies und # 4147 zusammenführen?

@BYK Ich denke, fast alles, was hier besprochen wurde, kann mit # 4147 zusammengeführt werden. Wie ich bereits sagte, denke ich, dass das einzige, was mich noch beschäftigt, die "Optimierungen" sind, die yarn install für yarn.lock selbst wenn keine Änderungen an package.json .

Mein Gedanke ist, dass diese Optimierungen als Zwischenstopp auf dem Weg zu Garn 2.0 deaktiviert werden sollten. Ich denke nicht, dass dies eine bahnbrechende Veränderung wäre.

Ich stimme zu 100% @artlogic zu .

Ich habe CircleCI eingerichtet und mein Build ist immer wieder fehlgeschlagen. Ich habe es bis zu einem Caching-Problem mit yarn.lock zurückverfolgt. Wenn ich von Rails komme, würde ich erwarten, dass die Sperrdatei bei einem Installationsbefehl gesperrt wird.

Dies wird für die Cache-Überprüfung auf CircleCI vorgeschlagen: https://circleci.com/docs/2.0/yarn/

#...
      - restore_cache:
          name: Restore Yarn Package Cache
          keys:
            - yarn-packages-{{ checksum "yarn.lock" }}
      - run:
          name: Install Dependencies
          command: yarn install
      - save_cache:
          name: Save Yarn Package Cache
          key: yarn-packages-{{ checksum "yarn.lock" }}
          paths:
            - ~/.cache/yarn
#...

Dies wird niemals funktionieren, da sich yarn.lock ändern kann, wenn dies nicht der Fall sein sollte.

Zu Ihrer Information, auf Garn 1.10.1 unter macOS 10.13.6 habe ich gerade den Bug-Stimulus des OP ausprobiert und festgestellt, dass yarn.lock nicht geändert wurde. Mit anderen Worten, als ich es versuchte:

yarn init
yarn add cordova
cp yarn.lock yarn.lock.initial
rm -r node_modules
yarn install
diff yarn.lock.initial yarn.lock

Also, wenn das Garn 1.10.1 verwendet wird , der yarn install nicht ändern yarn.lock , da es für die OP hatte , als Garn 1.0.1 verwenden. (Ich halte das für eine gute Sache, so wie ich es für das OP halte.)

@dtgriscom Das ist toll, dass das Problem für Cordova nicht mehr

Es wäre schön zu wissen, nicht wahr? Sie haben festgestellt, dass das Problem paketspezifisch war. Es ist sinnvoll, dass es auch versionierungsspezifisch sein kann. (Ich habe nie eine Rechtfertigung für "Wir wollen etwas ändern, das sich nicht ändern sollte" gehört; außer "Wir optimieren" ...)

Ich stimme voll und ganz zu, dass eine install -Operation standardmäßig deterministisch sein muss. Das Aktualisieren einer .lock -Datei sollte erfordern, dass der Entwickler eine Aktion ausführt, von der er weiß, dass sie eine Änderung in der Datei bewirkt. Sie könnten beispielsweise so etwas wie yarn install --optimize ausführen, um eine kleine Optimierung zu ermöglichen, die den aktuellen Status von Paketen nicht beeinträchtigt.

Das Hinzufügen separater Optionen, die ich in der Dokumentation nachschlagen muss, damit ich sicher sein kann, dass meine Sperrdatei ohne meine Erlaubnis unberührt bleibt, ist ziemlich verwirrend, insbesondere wenn sie zu Fehlern führen können. Als Entwickler erwarte ich, die Kontrolle über die von mir verwendeten Tools zu haben, und ich habe das Gefühl, dass dieses Verhalten mir das nimmt.

Bitte überdenken Sie das Umdrehen des Standardverhaltens, um die Sperrdatei nicht zu ändern und sie bei der Installation von Abhängigkeiten ausschließlich zu bearbeiten. Eine Integritätsprüfung mit der Warnung, dass package.json nicht mit der Sperrdatei synchronisiert ist, ist wirklich alles, was Menschen brauchen.

Ich habe Leuten gesagt, dass PRs, einschließlich Änderungen an der Sperrdatei, nicht zusammengeführt werden, da die Sperrdatei nur geändert wird, wenn neue Abhängigkeiten hinzugefügt oder aktualisiert werden. In der Installationsdokumentation heißt es:

yarn install

Installieren Sie alle in package.json aufgeführten Abhängigkeiten im lokalen Ordner node_modules .

Die yarn.lock -Datei wird wie folgt verwendet:

• Wenn yarn.lock vorhanden ist und ausreicht, um alle in package.json aufgeführten Abhängigkeiten zu erfüllen, werden die genauen Versionen von yarn.lock installiert und yarn.lock bleiben unverändert . Das Garn sucht nicht nach neueren Versionen.
• Wenn yarn.lock vorhanden ist oder nicht ausreicht, um alle in package.json aufgeführten Abhängigkeiten zu erfüllen (wenn Sie beispielsweise package.json manuell eine Abhängigkeit hinzufügen), sucht Yarn nach dem Neueste verfügbare Versionen, die die Einschränkungen in package.json erfüllen. Die Ergebnisse werden in yarn.lock .

Wenn Sie sicherstellen möchten, dass yarn.lock nicht aktualisiert wird, verwenden Sie --frozen-lockfile .

Ist die Dokumentation falsch, da es diese oben genannten Optimierungen gibt, oder ist dies ein Fehler, der vorerst berücksichtigt werden muss?

ps. es passiert immer noch und yarn --frozen-lockfile schlägt nicht fehl, wenn es passiert.

Ich verwende derzeit --frozen-lockfile in meiner .yarnrc -Datei, wodurch effektiv verhindert wird, dass Garn die Datei yarn.lock ändert, wenn yarn install auf verschiedenen Computern ausgeführt wird. Dies verhindert aber auch, dass yarn add blahblah mein yarn.lock ändert. Ist das das richtige Verhalten oder fehlt mir etwas? Ich habe den gesamten Thread durchgelesen und es scheint mir, dass --frozen-lockfile der empfohlene Ansatz für den Moment ist?

@konekoya Ja, Sie haben Recht, dass Sie derzeit verwenden müssen

yarn install --frozen-lockfile

und kann sich nicht auf die Einstellung in .yarnrc da dies verhindert, dass Ihre yarn.lock jemals aktualisiert werden.

Abhängig von Ihrem Inhalt von .npmrc und .yarnrc Sie möglicherweise verwenden

yarn install --no-default-rc {dependency}

aber ich würde mich nicht darauf verlassen (da es kaputt gehen würde, sobald du andere einstellungen in deinen rc-dateien hast.)

Siehe meinen Kommentar und das relevante Problem: # 4570, esp. meine Schlussfolgerung .

Danke, dass du das geklärt hast @ k0pernikus. Du hast gerade meinen Tag gemacht :)

@BYK Warum wendet Garn Optimierungen auf yarn.lock auf yarn install anstatt wenn add / upgrade werden?

Ich denke, der Kommentar von @ spencer-brown hier ist der Schlüssel zur "Behebung" dieses Problems. Ich habe gerade für mich selbst getestet und yarn upgrade und dann yarn Mir wurde gesagt, dass ich bereits auf dem neuesten Stand bin. Also habe ich meine node_modules gelöscht und yarn was dann zu der "optimierten" Sperrdatei führte, die die anderen Entwickler in meinem Projekt erhalten hätten, wenn ich die von yarn upgrade verschoben hätte

Wenn nun yarn upgrade (und yarn add ) dieselbe Optimierung wie yarn install ausführen würden, hätten wir dieses Problem überhaupt nicht. Es wurde viel darüber geredet, keine vorhandenen Funktionen brechen zu wollen, und ich sehe es nicht als etwas an, die Optimierung nach yarn upgrade und yarn add auszuführen - nur um sie etwas langsamer zu machen.

Um dieses Problem zu umgehen, möchte ich alle unsere Entwickler anweisen, node_modules zu löschen, wenn sie die Sperrdatei aktualisieren müssen, um die "Optimierung" zu erzwingen, bevor die Sperrdateien an andere weitergegeben werden. Oder vielleicht können sie yarn upgrade && yarn prune laufen lassen - vielleicht würde das den Trick machen?

Um dieses Problem zu umgehen, möchte ich alle unsere Entwickler anweisen, node_modules zu löschen, wenn sie die Sperrdatei aktualisieren müssen, um die "Optimierung" zu erzwingen, bevor die Sperrdateien an andere weitergegeben werden. Oder vielleicht können sie yarn upgrade && yarn prune ausführen - vielleicht würde das den Trick machen

Update: Sie können das Bereinigen nicht manuell ausführen. Sie erhalten lediglich die folgende Meldung: _ "Der Befehl zum Bereinigen ist nicht erforderlich. yarn install beschneidet externe Pakete" ._ Und da Sie die Installation auch nicht ausführen können, weil Sie sind _ "bereits auf dem neuesten Stand" _ Ich denke, wir werden Node_Module löschen und dann yarn ausführen, um das Beschneiden durchzuführen.

Für mich ist das größte Verkaufsargument für yarn ein vorhersehbares, zuverlässiges Verhalten von Sperrdateien. Das Ändern der Sperrdatei für yarn install macht mir wirklich Sorgen.

Für mich ist das größte Verkaufsargument für yarn ein vorhersehbares, zuverlässiges Verhalten von Sperrdateien. Das Ändern der Sperrdatei für yarn install macht mir wirklich Sorgen.

Die Sperrdatei wird als genaue Spezifikation der zu installierenden Elemente angezeigt, sodass wir uns keine Gedanken darüber machen müssen, was installiert werden soll. Verwenden Sie dieselbe Sperrdatei, und Sie erhalten jedes Mal dieselbe Installation. Aber manchmal ändert yarn sich aus aus eigenen Gründen und ohne Vorwarnung den Inhalt der Sperrdatei. Ja, Sie können argumentieren, dass "die Dateiänderungen nichts an der Installation ändern", aber warum sollten Sie eine so klare Garantie übernehmen und sie durcheinander bringen? Warum frage ich mich, ob ich die geänderte Sperrdatei erneut festschreiben soll? Warum besudeln Sie Ihren Hauptanspruch auf Ruhm?

Das ist wirklich unglaublich. Andere haben es bereits gut gesagt. Eine Sperrdatei sollte sich bei der Installation nicht ändern. Dies wirkt sich negativ auf Commit-Workflows aus. Jeder Entwickler in unserem Team weiß, unter welchen Umständen sich die Sperrdatei ändern darf. Wenn sich eine Sperrdatei ändert, ohne dass die Abhängigkeiten aktualisiert werden, führt dies zu unnötiger Verwirrung und zusätzlicher Überprüfung. Dies ist der grundlegende Paketmanager UX, der gerade kaputt ist. Bitte repariere.

Ich war gerade von diesem Verhalten überrascht, als ich von Node.js 13 auf 14 wechselte, änderten sich alle meine yarn.lock -Dateien, als ich ein yarn install und ich fragte mich, warum ...

Ich denke, das angemessene Verhalten wäre, eine Warnung auszugeben, wenn die Datei yarn.lock in irgendeiner Weise optimiert wird.