Yarn: Muss ich Garn.lock in .gitignore einfügen?

Sie sollten Garn.lock zu Ihrem Git hinzufügen , ignorieren Sie es nicht.

Siehe https://yarnpkg.com/en/docs/migrating-from-npm

Wenn Sie entweder yarn oder yarn add <package> ausführen, generiert Yarn eine yarn.lock Datei im Stammverzeichnis Ihres Pakets. Sie müssen diese Datei nicht lesen oder verstehen - checken Sie sie einfach in die Quellcodeverwaltung ein . Wenn andere Leute anfangen, Yarn anstelle von npm , stellt die yarn.lock Datei sicher, dass sie genau die gleichen Abhängigkeiten erhalten wie Sie.

Nur um das klarzustellen - dies gilt auch für Bibliotheken und nicht nur für Anwendungen, denn im Gegensatz zu npm-shrinkwrap.json nur die yarn.lock des Top-Level-Projekts verwendet, oder? Abhängigkeiten von Abhängigkeiten mit yarn.lock Dateien erzeugen also keine unnötigen Duplikate. Es ist nützlich für Bibliotheken, wenn Sie komplexe Entwicklungsabhängigkeiten haben und möchten, dass jeder Mitwirkende Ihrer Bibliothek die gleichen Build- und Testkonfigurationen hat.

Ist das richtig?

@goenning
Vielleicht ist es nicht immer die beste Idee, die Datei "garn.lock" in Ihr Repository zu legen.
ZB benutze ich Sinopia. Daher habe ich eine benutzerdefinierte npm-Registrierung. Ich verwende diese Registry hauptsächlich für andere Projekte, bei denen ich private Module habe.
Aber wenn ich ein öffentliches Projekt in ein Git-Repository pushe, das nur öffentliche Abhängigkeiten hat, hat das Garn.lock die falschen Links zu den Abhängigkeiten und mein CI-System kann das Projekt nicht erstellen.
Die Abhängigkeiten verweisen auf mein lokales Repository.
Dies kann auch anderen Entwicklern passieren, wenn sie mein Repository klonen.
Gibt es eine Möglichkeit, dies zu umgehen, außer die Datei "garn.lock" in den Giignore zu legen?

Wenn Sie die npm-Registry vorauthentifiziert haben, zB myget, das Proxys für npm ist, werden yarn.lock vorauthentifizierte Links zu Paketen haben, was eine schwerwiegende Sicherheitsverletzung darstellt 🎉
Dies sollte irgendwo mit großer Schrift dokumentiert werden.

@Pfeifenjoy was ist, wenn Sie mit dem git-Submodul anstelle von npm auf private Pakete verlinken?
Mit git können Sie mit dem Deploy-Schlüssel auf das Repository zugreifen (über ssh)

@beenotung Ich bin kein großer Fan davon, git als Abhängigkeitsmanager zu verwenden, da es sehr langsam ist, Abhängigkeiten nicht so auflöst, wie ich es möchte, und meiner Meinung nach ist es am besten, jede Abhängigkeit in einem Manager zu haben.

Auch die Abhängigkeiten, auf die ich referenziere, erhalten alle (nicht nur meine eigenen Projekte) eine andere Adresse, da sie in meinem lokalen sinopia-Konto gespeichert sind. Es wäre sehr mühsam, alle Knotenmodule, von denen meine Projekte abhängig sind, in git zu referenzieren.
Außerdem ist es einfacher, die Datei "garn.lock" zu entfernen.

@Pfeifenjoy Gibt es möglicherweise einen Konflikt darin, was Garn tun soll? Wenn Sie eine Möglichkeit bieten möchten, sicherzustellen, dass andere Installationen Ihre Abhängigkeiten aufweisen, fügen Sie sie ein – sie funktioniert wie beabsichtigt. Wenn Sie private Repositorys und Quellen abrufen, sollten Sie sehr vorsichtig sein, wie Sie Ihren Code pro-sagen teilen, genauso wie Sie speziell alle Schlüssel oder Salts aus einem Repository ignorieren würden (wenn Sie a Warnung in der Projekt-Readme, ich würde eine Feature-/Pull-Anfrage stellen).

Möglicherweise sollte Garn beim Ausführen eine Warnung ausgeben, um einen Benutzer zu warnen, dass der Zugriff auf eine authentifizierte Quelle in der Sperrdatei enthalten ist, aber auch dies wäre eine Funktionsanforderung.

@thisolivier klingt vernünftig

Nur eine Notiz.
Wegen https://github.com/yarnpkg/yarn/issues/3330 sollten Sie yarn.lock hinzufügen, wenn Sie in China oder einem anderen eingeschränkten Gebiet leben und Ihr Modul mit einer anderen Registrierung (z. B. Taobao) erstellen .gitignore und schreibe package-lock = false in .npmrc.

Hier, warum ich meine Garn.lock nicht Garn.lock generiert wird).
Um meine Benutzer glücklich zu machen und eine fehlerfreie Installation zu gewährleisten, entferne ich Garn - es sei denn, Garn bietet eine Lösung mit einer klaren Dokumentation, wie das Problem gelöst werden kann, dann stimme ich zu.
(Höre immer vom Entwickler die wahre Geschichte)

Außerdem macht es deine Commits wirklich hässlich.

Ich stimme dem am meisten positiv bewerteten Kommentar hier nicht zu:

• Wenn das Projekt npm verwendet, übergeben Sie package-lock.json an das Repository und gitignore yarn.lock
• Wenn das Projekt Garn verwendet, übergeben Sie yarn.lock an das Repo und gitignore package-lock.json

Das heißt, sollten Sie _nicht_ immer yarn.lock an den Repo zu begehen und zu Frage Antwort OP, ja man könnte es hinzufügen möchten .gitignore .

Wenn andere Leute anfangen, Yarn anstelle von npm zu verwenden, stellt die Dateigarn.lock sicher, dass sie genau die gleichen Abhängigkeiten erhalten wie Sie

Zunächst einmal, nein, das wird es nicht - nur wenn Sie immer nur die öffentliche npm-Registrierung verwenden. Schlimmer noch, wenn Sie in Garn nicht für Ihre private Organisation authentifiziert sind (auch wenn Sie noch in npm sind) und ein Paket mit demselben Namen in der öffentlichen Registrierung vorhanden ist, wird einfach das falsche Paket ohne Aufforderung installiert. Es wäre verwirrend, warum Ihr Garn ohne Fehler installiert wird, die App jedoch nicht funktioniert, wenn Sie Garn verwenden, aber bei Verwendung von npm.

Zweitens verwenden viele Codebasen _kein_ Garn. Es geht nicht darum, "wann sie auf Garn umsteigen". Fast alle meine Node-Dienste und grundlegenden Webserver verwenden npm ohne Pläne, auf Garn umzusteigen. Ich mag Garn mit React, das war es auch schon.

Wie @Pfeifenjoy oben erwähnt:

Ich habe eine benutzerdefinierte npm-Registrierung. Ich benutze diese Registry hauptsächlich für andere Projekte, bei denen ich private Module habe

Aber wenn ich ein öffentliches Projekt in ein Git-Repository pushe, das nur öffentliche Abhängigkeiten hat, hat das Garn.lock die falschen Links zu den Abhängigkeiten und mein CI-System kann das Projekt nicht erstellen.

^ Eine andere Sache, selbst wenn Sie es lokal lösen, müssen Sie die Lösung in die yaml- oder sonstige Konfiguration für CI integrieren und an einer anderen Stelle die App starten - eine Art Logik, die erkennen kann, wann welche Registrierung und welcher Befehl verwendet werden soll - klingt nervig und unnötig

Eine andere Sache - wenn Sie jeden ermutigen, immer yarn.lock in das Repo zu übernehmen und es nie zu ignorieren, werden Entwickler anfangen, Garn in einem Repo zu verwenden, das bereits stark auf npm angewiesen ist. Selbst in den Fällen, in denen es gut funktioniert, wird es Redundanzen in den 2 Lock-Dateien geben, und es öffnet eine Tür zur Hölle der Abhängigkeiten. Und du weißt, dass irgendein Entwickler irgendwann eine ~25.000 Zeile yarn.lock begehen wird, die dein Beitragsdiagramm durcheinander bringt :joy: