Was ist der Unterschied zwischen npm-shrinkwrap.json und package-lock.json?

158

Mit der Veröffentlichung von npm @ 5 wird nun ein geschrieben, package-lock.jsonsofern noch kein npm-shrinkwrap.jsonvorhanden ist.

Ich habe npm @ 5 global installiert über:

npm install npm@5 -g

Und jetzt, wenn a npm-shrinkwrap.jsongefunden wird während:

npm install

Eine Warnung wird gedruckt:

npm WARN read-shrinkwrap This version of npm
is compatible with lockfileVersion@1,
but npm-shrinkwrap.json was generated for lockfileVersion@0.
I'll try to do my best with it!

Mein Take-Away ist also, dass ich die Schrumpffolie durch die ersetzen sollte package-lock.json.

Doch warum gibt es dafür ein neues Format? Was können die package-lock.jsontun, npm-shrinkwrap.jsonwas nicht?

npm npm-shrinkwrap package-lock.json

— k0pernikus
quelle

Antworten:

176

Die Dateien haben genau den gleichen Inhalt, aber es gibt eine Handvoll Unterschiede in der Art und Weise, wie npm damit umgeht. Diese werden auf der Dokumentenseite und auch in einer Dokumentdatei im npm-Repo beschrieben, in der zunächst explizit auf den Unterschied zwischen diesen beiden Dateien eingegangen wird :

package-lock.jsonwird nie in npm veröffentlicht, wohingegen npm-shrinkwrapstandardmäßig
package-lock.json Dateien, die nicht im Top-Level-Paket enthalten sind, werden ignoriert, Shrinkwrap-Dateien, die zu Abhängigkeiten gehören, werden jedoch berücksichtigt
npm-shrinkwrap.jsonist abwärtskompatibel mit den npm-Versionen 2, 3 und 4, package-lock.jsonwird jedoch nur von npm 5+ erkannt

Sie können ein vorhandenes package-lock.jsonin ein konvertieren , npm-shrinkwrap.jsonindem Sie es ausführen npm shrinkwrap.

So:

Wenn Sie Ihr Paket nicht auf npm veröffentlichen, ist die Wahl zwischen diesen beiden Dateien von geringer Bedeutung. Möglicherweise möchten Sie verwenden, package-lock.jsonda dies die Standardeinstellung ist und der Name für npm-Anfänger klarer ist. Alternativ können Sie die npm-shrinkwrap.jsonAbwärtskompatibilität mit npm 2-4 verwenden, wenn es für Sie schwierig ist, sicherzustellen, dass alle Mitglieder Ihres Entwicklungsteams auf npm 5+ eingestellt sind. (Beachten Sie, dass npm 5 am 25. Mai 2017 veröffentlicht wurde. Die Abwärtskompatibilität wird immer weniger wichtig, je weiter wir von diesem Datum entfernt sind, da die meisten Benutzer irgendwann ein Upgrade durchführen werden.)
Wenn Sie werden Ihr Paket zu npm veröffentlichen, haben Sie die Wahl zwischen:
1. Verwenden Sie a package-lock.json, um genau aufzuzeichnen, welche Versionen von Abhängigkeiten Sie installiert haben. Ermöglichen Sie jedoch den Benutzern, die Ihr Paket installieren, die Verwendung einer beliebigen Version der Abhängigkeiten, die mit den von Ihnen package.jsonoder vorgegebenen Versionsbereichen kompatibel ist
2. Verwenden Sie a, npm-shrinkwrap.jsonum sicherzustellen, dass jeder, der Ihr Paket installiert, genau die gleiche Version aller Abhängigkeiten erhält
Die offizielle Ansicht, die (sehr knapp) in den Dokumenten beschrieben wird, ist, dass Option 1 für Bibliotheken verwendet werden sollte (vermutlich, um das Ausmaß der Paketduplizierung zu verringern, das verursacht wird, wenn viele Abhängigkeiten eines Pakets alle von geringfügig unterschiedlichen Versionen derselben sekundären Abhängigkeit abhängen). Diese Option 2 ist jedoch möglicherweise für ausführbare Dateien sinnvoll, die global installiert werden sollen.

— Mark Amery
quelle

+1 - können Sie Ihren zweiten Punkt klarstellen? Was ist der Unterschied zwischen diesem Verhalten und einem npm-Shrinkwrap?

— Rhys

@Rhys die zweite Kugel spielt in der Praxis keine Rolle, es sei denn, Sie tun etwas Seltsames. Grundsätzlich heißt es nur, dass wenn eine Bibliothek irgendwie eine veröffentlicht hätte package-lock.json(was nicht möglich ist), wenn Sie diese Bibliothek als Abhängigkeit von einem anderen Paket installieren package-lock.jsonwürden , die Bibliotheken von NPM ignoriert würden. Wenn eine Bibliothek jedoch eine npm-shrinkwrap.jsonveröffentlicht und Sie die Bibliothek als Abhängigkeit installieren, installieren Sie auch die genauen Versionen aller in der Bibliothek angegebenen Abhängigkeiten als sekundäre Abhängigkeiten npm-shrinkwrap.json.

— Mark Amery

Können Sie bitte hinzufügen, dass npm civorhanden, um die Installation der package-lock.jsonals schreibgeschützt zu versichern . ( npm installmutiert die package-lock.jsonverursachende Verwirrung und mögliche Fehler und nutzt die package-lock.jsonper se nicht aus.)

— k0pernikus

@ k0pernikus Ich glaube nicht, dass es einen Unterschied gibt, wie npm cibehandelt wird npm-shrinkwrap.jsonund package-lock.json- welche Relevanz hat diese Frage für den Unterschied zwischen den beiden Dateien? Außerdem, nachdem ich herumgelesen habe: Ich denke, dass " npm install... das nicht ausnutzt package-lock.json" seit npm 5.4 falsch ist - ich glaube, npm installjetzt respektiere ich Sie, es package-lock sei denn, es ist völlig inkompatibel mit Ihrem package.json. In diesem Fall hat letzteres Vorrang. (Aber ich war ein bisschen außerhalb der JavaScript-Welt - vermisse ich etwas?)

— Mark Amery

Erklärung vom NPM-Entwickler :

Die Idee ist definitiv, dass package-lock.json die neueste und beste in der Shrinkwrap-Technologie ist und npm-shrinkwrap.json für die wenigen kostbaren Leute da draußen reserviert ist, denen es sehr wichtig ist, dass ihre Bibliotheken ein genaues node_modules haben - und Für Benutzer, die möchten, dass CI mit npm @> = 2 einen bestimmten Baum installiert, ohne die npm-Version anstoßen zu müssen.

Die neue Sperrdatei ("package-lock.json") hat im Grunde den gleichen Code, genau das gleiche Format wie npm-shrinkwrap (Sie können sie untereinander umbenennen!). Es ist auch etwas, was die Community zu verstehen scheint: "Es hat eine Sperrdatei" scheint bei Menschen so viel schneller zu klicken. Schließlich bedeutete eine neue Datei, dass wir ein relativ geringes Risiko für die Abwärtskompatibilität mit Shrinkwrap haben konnten, ohne seltsame Dinge wie die im übergeordneten Beitrag erwähnte Erlaubnis zur Veröffentlichung tun zu müssen.

— SeriousM
quelle

Der Unterschied ist mir immer noch nicht klar. Wenn npm-shrinkwrapist für genaue node_modules .... Ich nehme an, package-lock.jsonist das Sperren weniger als genau? Und wenn ja, was ist nicht Sperren, npm-shrinkwrapdas sperrt?

— Dman

du hast es falsch verstanden @dman. package-lock ist die neue Version von npm-shrinkwrap. Die Paketsperre ist deaktiviert (Sie müssen die Funktion entfernen, da sie standardmäßig aktiviert ist). Npm-shrinkwrap ist deaktiviert (Sie müssen sie aktivieren, da sie nicht in meiner Standardeinstellung enthalten ist). Der Grund, warum sie die Paketsperre eingeführt haben, ist, dass 1. Benutzer jetzt eine sicherere Möglichkeit haben, mit Abhängigkeiten umzugehen, da diese standardmäßig aktiviert sind, und 2. der Name impliziert, was es im Gegensatz zu "Shrinkwrap" gibt. npm-shrinkwrap hatte einige spezielle Einstellungen für das Abhängigkeitsverhalten, die die Paketsperre jetzt nicht hat. npm-shrinkwrap ist jetzt veraltet.

— SeriousM

Das ist falsch. Wenn Sie sagen, dass package-lock die neue Version von npm-shrinkwrap ist, sagen Sie, dass es ein Ersatz ist. npm-shrinkwrap ist nicht veraltet und unterscheidet sich von package-lock.json. Darüber hinaus hat package-lock.json einen Fehler, während npm-shrinkwrap dies nicht tut. Daher wird mehr betont, dass es sich nicht um denselben Code handelt.

— Dman

Auch package-lock.json ist aufdringlich. Daher kann es leicht zu SCM-Konflikten kommen, wenn Sie "npm i" aufrufen, während Shrinkwrap explizit generiert werden soll und keine Konflikte auf CI-Servern verursacht. Ja, ich kann mich hier irren.

— Norekhov

@dman "package-lock.json hat einen Fehler, npm-shrinkwrap nicht" - nein, nicht. In dem von Ihnen verlinkten Thema gibt es keinen Hinweis darauf. es wird nicht einmal erwähnt npm-shrinkwrap. Wie ich in meiner Antwort feststelle, erfolgt die Konvertierung von a package-lock.jsonin a npm-shrinkwrap.jsonbuchstäblich nur durch Umbenennen der Datei. Sie sind "der gleiche Code".

— Mark Amery

Ich denke, die Idee war, dass --Save und Shrinkwrap standardmäßig ausgeführt werden, aber mögliche Probleme mit einem Shrinkwrap vermieden werden, wenn es nicht gewünscht wird. Also gaben sie ihm einfach einen neuen Dateinamen, um Konflikte zu vermeiden. Jemand von npm hat es hier ausführlicher erklärt:

https://www.reddit.com/r/javascript/comments/6dgnnq/npm_v500_released_save_by_default_lockfile_better/di3mjuk/

Das entsprechende Zitat:

npm veröffentlicht standardmäßig die meisten Dateien in Ihrem Quellverzeichnis, und seit Jahren veröffentlichen Benutzer Shrinkwraps. Wir wollten die Kompatibilität nicht brechen. Bei standardmäßig --save und shrinkwrap bestand ein großes Risiko, dass es versehentlich in die Registrierung aufgenommen und dort weitergegeben wurde, und unsere Fähigkeit, deps zu aktualisieren und zu deduplizieren, ist im Grunde genommen null.

Also haben wir einen neuen Namen gewählt. Und wir haben plötzlich einen neuen Namen gewählt. Die neue Sperrdatei teilt im Grunde den gleichen Code, genau das gleiche Format

— Cody Brumfield
quelle