Warum schreibt "npm install" package-lock.json neu?

Ich habe kürzlich ein Upgrade auf npm @ 5 durchgeführt . Ich habe jetzt eine package-lock.json- Datei mit allem von package.json . Ich würde erwarten, dass beim Ausführen npm installdie Abhängigkeitsversionen aus der Sperrdatei abgerufen werden, um zu bestimmen, was in meinem Verzeichnis node_modules installiert werden soll . Was seltsam ist, ist, dass es tatsächlich dazu führt, dass meine package-lock.json- Datei geändert und neu geschrieben wird.

Für die Sperrdatei wurde beispielsweise Typoskript in Version 2.1.6 angegeben . Nach dem npm installBefehl wurde die Version in 2.4.1 geändert . Das scheint den ganzen Zweck einer Sperrdatei zu zunichte zu machen.

Was vermisse ich? Wie kann ich npm dazu bringen, meine Sperrdatei tatsächlich zu respektieren?

Update 3: Wie auch andere Antworten zeigen, wurde der npm ciBefehl in npm 5.7.0 eingeführt, um schnelle und reproduzierbare Builds im CI-Kontext zu erzielen. Weitere Informationen finden Sie in der Dokumentation und im npm-Blog .

Update 2: Das Problem zum Aktualisieren und Verdeutlichen der Dokumentation ist das GitHub-Problem Nr. 18103 .

Update 1: Das unten beschriebene Verhalten wurde in npm 5.4.2 behoben: Das derzeit beabsichtigte Verhalten wird in GitHub-Problem Nr. 17979 beschrieben .

Ursprüngliche Antwort: Das Verhalten von package-lock.jsonwurde in npm 5.1.0 geändert, wie in Ausgabe 16866 beschrieben . Das von Ihnen beobachtete Verhalten ist anscheinend von npm ab Version 5.1.0 beabsichtigt.

Das bedeutet, dass package.jsondies überschrieben werden kann, package-lock.jsonwenn eine neuere Version für eine Abhängigkeit in gefunden wird package.json. Wenn Sie Ihre Abhängigkeiten effektiv anheften möchten, müssen Sie jetzt die Versionen ohne Präfix angeben, z. B. müssen Sie sie 1.2.0anstelle von ~1.2.0oder schreiben ^1.2.0. Dann ergibt die Kombination von package.jsonund package-lock.jsonreproduzierbare Builds. Um es klar auszudrücken: package-lock.jsonAllein sperrt die Abhängigkeiten auf Stammebene nicht mehr!

Ob diese Entwurfsentscheidung gut war oder nicht, ist fraglich. Aufgrund dieser Verwirrung über GitHub in Ausgabe 17979 wird derzeit diskutiert . (In meinen Augen ist es eine fragwürdige Entscheidung; zumindest gilt der Name locknicht mehr.)

Noch eine Randnotiz: Es gibt auch eine Einschränkung für Registries, die unveränderliche Pakete nicht unterstützen, z. B. wenn Sie Pakete direkt von GitHub anstelle von npmjs.org abrufen. Weitere Erläuterungen finden Sie in dieser Dokumentation zu Paketsperren .

Ich habe , dass es fand eine neue Version von npm sein 5.7.1 mit dem neuen Befehl npm ci, die aus installieren package-lock.jsonnur

Der neue Befehl npm ci wird NUR von Ihrer Sperrdatei installiert. Wenn Ihre package.json und Ihre Sperrdatei nicht synchron sind, wird ein Fehler gemeldet.

Es funktioniert, indem Sie Ihre node_modules wegwerfen und von Grund auf neu erstellen.

Abgesehen davon, dass Sie nur das erhalten, was sich in Ihrer Sperrdatei befindet, ist es auch viel schneller (2x-10x!) Als die npm-Installation, wenn Sie nicht mit einem node_modules beginnen.

Wie Sie dem Namen entnehmen können, erwarten wir, dass dies ein großer Segen für Umgebungen mit kontinuierlicher Integration ist. Wir erwarten auch, dass Leute, die Produktionsbereitstellungen von Git-Tags durchführen, große Gewinne erzielen werden.

Verwenden Sie die neu eingeführte

npm ci

npm ci verspricht großen Teams den größten Nutzen. Wenn Entwickler die Möglichkeit erhalten, sich von einer Paketsperre abzumelden, wird die Zusammenarbeit zwischen großen Teams effizienter, und durch die Möglichkeit, genau das zu installieren, was sich in einer Sperrdatei befindet, können zehn, wenn nicht Hunderte von Entwicklerstunden pro Monat eingespart werden, wodurch Teams frei werden um mehr Zeit damit zu verbringen, erstaunliche Dinge zu bauen und zu versenden.

Einführung npm cifür schnellere und zuverlässigere Builds

Kurze Antwort:

• npm install ehrt package-lock.json nur, wenn es die Anforderungen von package.json erfüllt.
• Wenn diese Anforderungen nicht erfüllt werden, werden die Pakete aktualisiert und die Paketsperre überschrieben.
• Wenn Sie den Build lieber nicht bestehen, als in diesem Fall die Paketsperre neu zu schreiben, verwenden Sie npm ci.

Hier ist ein Szenario, das die Dinge erklären könnte (Verifiziert mit NPM 6.3.0).

Sie deklarieren eine Abhängigkeit in package.json wie folgt:

"depA": "^1.0.0"

Dann tun Sie dies, npm installwodurch eine package-lock.json generiert wird mit:

"depA": "1.0.0"

Wenige Tage später wird eine neuere Nebenversion von "depA" veröffentlicht, beispielsweise "1.1.0". Dann gilt Folgendes:

npm ci       # respects only package-lock.json and installs 1.0.0

npm install  # also, respects the package-lock version and keeps 1.0.0 installed 
             # (i.e. when package-lock.json exists, it overrules package.json)

Als Nächstes aktualisieren Sie Ihre package.json manuell auf:

"depA": "^1.1.0"

Führen Sie dann erneut aus:

npm ci      # will try to honor package-lock which says 1.0.0
            # but that does not satisfy package.json requirement of "^1.1.0" 
            # so it would throw an error 

npm install # installs "1.1.0" (as required by the updated package.json)
            # also rewrites package-lock.json version to "1.1.0"
            # (i.e. when package.json is modified, it overrules the package-lock.json)

Verwenden Sie den npm ciBefehl anstelle von npm install.

"ci" steht für "kontinuierliche Integration".

Es werden die Projektabhängigkeiten basierend auf der Datei package-lock.json anstelle der milden Abhängigkeiten der Datei package.json installiert.

Es werden identische Builds für Ihre Teamkollegen erstellt und es ist auch viel schneller.

Sie können mehr darüber in diesem Blog-Beitrag lesen: https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

In Zukunft können Sie ein --from-lock-file(oder ein ähnliches) Flag verwenden, um nur von zu installieren, package-lock.jsonohne es zu ändern.

Dies ist nützlich für CI-Umgebungen usw., in denen reproduzierbare Builds wichtig sind.

Sehen Informationen zur Verfolgung der Funktion finden https://github.com/npm/npm/issues/18286 .

Es scheint, dass dieses Problem in npm v5.4.2 behoben ist

https://github.com/npm/npm/issues/17979

(Scrolle nach unten zum letzten Kommentar im Thread)

Aktualisieren

Eigentlich in 5.6.0 behoben. In 5.4.2 gab es einen plattformübergreifenden Fehler, der dazu führte, dass das Problem weiterhin auftrat.

https://github.com/npm/npm/issues/18712

Update 2

Siehe meine Antwort hier: https://stackoverflow.com/a/53680257/1611058

npm ci ist der Befehl, den Sie verwenden sollten, wenn Sie jetzt vorhandene Projekte installieren.

Sie haben wahrscheinlich so etwas wie:

"typescript":"~2.1.6"

In package.jsonIhrem Fall wird npm auf die neueste Nebenversion aktualisiert2.4.1

Bearbeiten: Frage von OP

Das erklärt aber nicht, warum "npm install" die Sperrdatei ändern würde. Ist die Sperrdatei nicht dazu gedacht, einen reproduzierbaren Build zu erstellen? In diesem Fall sollte unabhängig vom Semver-Wert dieselbe Version 2.1.6 verwendet werden.

Antworten:

Dies soll Ihren vollständigen Abhängigkeitsbaum sperren. Sagen wir typescript v2.4.1erfordert widget ~v1.0.0. Wenn Sie npm installieren, greift es widget v1.0.0. Später führt Ihr Entwicklerkollege (oder CI-Build) eine npm-Installation durch und erhält diese typescript v2.4.1, widgetwurde jedoch aktualisiert widget v1.0.1. Jetzt ist Ihr Knotenmodul nicht mehr synchron. Das ist waspackage-lock.json verhindert.

Oder allgemeiner:

Betrachten Sie als Beispiel

Paket A:

{"name": "A", "version": "0.1.0", "dependencies": {"B": "<0.1.0"}}

Paket B:

{"Name": "B", "Version": "0.0.1", "Abhängigkeiten": {"C": "<0.1.0"}}

und Paket C:

{"name": "C", "version": "0.0.1"}

Wenn dies die einzigen Versionen von A, B und C sind, die in der Registrierung verfügbar sind, wird eine normale npm-Installation A installiert:

A@0.1.0 - B@0.0.1 - C@0.0.1

Wenn jedoch B@0.0.2 veröffentlicht wird, wird eine neue npm-Installation A installiert:

A@0.1.0 - B@0.0.2 - C@0.0.1 unter der Annahme, dass die neue Version die Abhängigkeiten von B nicht geändert hat. Natürlich könnte die neue Version von B eine neue Version von C und eine beliebige Anzahl neuer Abhängigkeiten enthalten. Wenn solche Änderungen unerwünscht sind, kann der Autor von A eine Abhängigkeit von B@0.0.1 angeben. Wenn jedoch der Autor von A und der Autor von B nicht dieselbe Person sind, kann der Autor von A nicht sagen, dass er oder sie keine neu veröffentlichten Versionen von C abrufen möchte, wenn sich B überhaupt nicht geändert hat.

OP Frage 2: Lassen Sie mich sehen, ob ich richtig verstehe. Sie sagen, dass die Sperrdatei die Versionen der sekundären Abhängigkeiten angibt, sich jedoch weiterhin auf den Fuzzy-Abgleich von package.json stützt, um die Abhängigkeiten der obersten Ebene zu bestimmen. Ist das richtig?

Antwort: Nein. Package-Lock sperrt den gesamten Paketbaum, einschließlich der in beschriebenen Root-Pakete package.json. Wenn in Ihrem typescriptgesperrt ist , sollte dies so bleiben, bis es geändert wird. Und sagen wir, morgen wird die Version veröffentlicht . Wenn ich Ihren Zweig auschecke und ausführe , respektiert npm die Sperrdatei und installiert sie .2.4.1package-lock.jsontypescript2.4.2npm install2.4.1

Mehr zu package-lock.json:

package-lock.json wird automatisch für alle Vorgänge generiert, bei denen npm entweder den Baum node_modules oder package.json ändert. Es beschreibt den genauen Baum, der generiert wurde, sodass nachfolgende Installationen unabhängig von Zwischenabhängigkeitsaktualisierungen identische Bäume generieren können.

Diese Datei soll in Quell-Repositorys festgeschrieben werden und dient verschiedenen Zwecken:

Beschreiben Sie eine einzelne Darstellung eines Abhängigkeitsbaums, sodass Teammitglieder, Bereitstellungen und kontinuierliche Integration garantiert genau dieselben Abhängigkeiten installieren.

Bieten Sie Benutzern die Möglichkeit, "Zeitreisen" zu früheren Status von node_modules zu unternehmen, ohne das Verzeichnis selbst festschreiben zu müssen.

Um eine bessere Sichtbarkeit von Baumänderungen durch lesbare Unterschiede in der Quellcodeverwaltung zu ermöglichen.

Optimieren Sie den Installationsprozess, indem Sie npm erlauben, wiederholte Metadatenauflösungen für zuvor installierte Pakete zu überspringen.

https://docs.npmjs.com/files/package-lock.json

Wahrscheinlich sollten Sie so etwas verwenden

npm ci

Anstatt zu verwenden npm install wenn Sie die Version Ihres Pakets nicht ändern möchten.

Befolgen Sie gemäß der offiziellen Dokumentation beide npm installund npm ciinstallieren Sie die Abhängigkeiten, die für das Projekt benötigt werden.

Der Hauptunterschied besteht darin, npm installdie Pakete packge.jsonals Referenz zu installieren . In diesem Fall werden npm cidie Pakete package-lock.jsonals Referenz installiert , wobei jedes Mal sichergestellt wird, dass das genaue Paket installiert wird.

Es gibt ein offenes Problem dafür auf ihrer Github-Seite: https://github.com/npm/npm/issues/18712

Dieses Problem ist am schwerwiegendsten, wenn Entwickler unterschiedliche Betriebssysteme verwenden.

EDIT: Der Name "Lock" ist schwierig, sein NPM versucht, Yarn einzuholen. Es ist überhaupt keine gesperrte Datei. package.jsonist eine vom Benutzer festgelegte Datei, die nach der "Installation" den Ordnerbaum "node_modules" generiert und in diesen Baum geschrieben wird package-lock.json. Sie sehen, es ist umgekehrt - Abhängigkeitsversionen werden package.jsonwie immer package-lock.jsonabgerufen und sollten aufgerufen werdenpackage-tree.json

(Ich hoffe, dies hat meine Antwort nach so vielen Abstimmungen klarer gemacht.)

Eine vereinfachende Antwort: package.jsonHaben Sie Ihre Abhängigkeiten wie gewohnt, während package-lock.jsones sich um einen "exakten und vor allem reproduzierbaren node_modules-Baum" handelt (entnommen aus npm docs selbst ).

Was den kniffligen Namen betrifft, so versucht sein NPM, Yarn einzuholen.