Muss ich die von npm 5 erstellte Datei package-lock.json festschreiben?

npm 5 wurde heute veröffentlicht und eine der neuen Funktionen umfasst deterministische Installationen mit der Erstellung einer package-lock.jsonDatei.

Soll diese Datei in der Quellcodeverwaltung aufbewahrt werden?

Ich gehe davon aus, dass es ähnlich ist yarn.lockund composer.lock, die beide in der Quellcodeverwaltung bleiben sollen.

Ja, package-lock.jsonsoll in die Quellcodeverwaltung eingecheckt werden. Wenn Sie npm 5 verwenden, wird dies möglicherweise in der Befehlszeile angezeigt: created a lockfile as package-lock.json. You should commit this file.Laut npm help package-lock.json:

package-lock.jsonwird automatisch für alle Vorgänge generiert, bei denen npm entweder den node_modulesBaum oder ändert package.json. 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" in frühere Zustände node_moduleszu 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.

Ein wichtiges Detail package-lock.jsonist, dass es nicht veröffentlicht werden kann und ignoriert wird, wenn es an einem anderen Ort als dem Toplevel-Paket gefunden wird. Es teilt ein Format mit npm-shrinkwrap.json (5), das im Wesentlichen dieselbe Datei ist, jedoch die Veröffentlichung ermöglicht. Dies wird nur empfohlen, wenn ein CLI-Tool bereitgestellt oder der Veröffentlichungsprozess für die Erstellung von Produktionspaketen anderweitig verwendet wird.

Wenn beide package-lock.jsonund npm-shrinkwrap.jsonim Stammverzeichnis eines Pakets vorhanden sind, package-lock.jsonwird dies vollständig ignoriert.

Ja, es soll eingecheckt werden. Ich möchte vorschlagen, dass es ein eigenes Commit erhält. Wir stellen fest, dass es unseren Unterschieden viel Lärm hinzufügt.

Ja du solltest:

1. begehen die package-lock.json.
2. Verwenden Sie diese npm ciOption nicht,npm install wenn Sie Ihre Anwendungen sowohl auf Ihrem CI als auch auf Ihrem lokalen Entwicklungscomputer erstellen

Der npm ciWorkflow erfordert das Vorhandensein von a package-lock.json.

Ein großer Nachteil des npm installBefehls ist sein unerwartetes Verhalten, das ihn möglicherweise mutiert package-lock.json, während npm cinur die in der Sperrdatei angegebenen Versionen verwendet werden und ein Fehler auftritt

• wenn die package-lock.jsonund package.jsonnicht synchron sind
• wenn a package-lock.jsonfehlt.

Daher läuft npm installlokal, insb. In größeren Teams mit mehreren Entwicklern kann es zu vielen Konflikten innerhalb der package-lock.jsonund Entwickler kommen, um zu entscheiden, die package-lock.jsonstattdessen vollständig zu löschen .

Es gibt jedoch einen starken Anwendungsfall, um darauf vertrauen zu können, dass die Abhängigkeiten des Projekts auf verschiedenen Maschinen zuverlässig und zuverlässig wiederholt werden.

Von einem erhalten package-lock.jsonSie genau das: einen bekannten Arbeitszustand.

In der Vergangenheit hatte ich Projekte ohne package-lock.json/ npm-shrinkwrap.json/ yarn.lockDateien , deren Build eines Tages scheitern , weil eine zufällige Abhängigkeit eine Bruch Update bekam.

Diese Probleme sind schwer zu lösen, da Sie manchmal raten müssen, was die letzte Arbeitsversion war.

Wenn Sie eine neue Abhängigkeit hinzufügen möchten, werden Sie weiterhin ausgeführt npm install {dependency}. Wenn Sie ein Upgrade durchführen möchten, verwenden Sie entweder npm update {dependency}oder npm install ${dependendency}@{version}und übernehmen Sie die Änderung package-lock.json.

Wenn ein Upgrade fehlschlägt, können Sie zur letzten bekannten Funktion zurückkehren package-lock.json.

Um npm doc zu zitieren :

Es wird dringend empfohlen, die generierte Paketsperre für die Quellcodeverwaltung festzulegen: Auf diese Weise können alle anderen Mitglieder Ihres Teams, Ihre Bereitstellungen, Ihre CI / kontinuierliche Integration und alle anderen Personen, die npm install in Ihrer Paketquelle ausführen, genau denselben Abhängigkeitsbaum erhalten dass du dich weiterentwickelt hast. Darüber hinaus sind die Unterschiede zu diesen Änderungen für Menschen lesbar und informieren Sie über alle Änderungen, die npm an Ihren node_modules vorgenommen hat, sodass Sie feststellen können, ob transitive Abhängigkeiten aktualisiert, angehoben usw. wurden.

Und in Bezug auf den Unterschied zwischen npm civsnpm install :

• Das Projekt muss über eine vorhandene package-lock.json oder npm-shrinkwrap.json verfügen.
• Wenn die Abhängigkeiten in der Paketsperre nicht mit denen in package.json übereinstimmen, npm ciwird sie mit einem Fehler beendet, anstatt die Paketsperre zu aktualisieren.
• npm ci Es können nur ganze Projekte gleichzeitig installiert werden: Mit diesem Befehl können keine einzelnen Abhängigkeiten hinzugefügt werden.
• Wenn a node_modulesbereits vorhanden ist, wird es automatisch entfernt, bevor npm cimit der Installation begonnen wird.
• Es wird niemals in package.jsonoder eines der Paketschlösser geschrieben: Installationen werden im Wesentlichen eingefroren.

Hinweis: Ich stellte eine ähnliche Antwort hier

Ja, die beste Vorgehensweise ist das Einchecken (JA, CHECK-IN).

Ich bin damit einverstanden, dass es beim Betrachten des Diff viel Lärm oder Konflikte verursacht. Aber die Vorteile sind:

1. garantieren genau die gleiche Version jedes Pakets . Dieser Teil ist am wichtigsten, wenn Sie zu unterschiedlichen Zeiten in unterschiedlichen Umgebungen bauen. Sie können ^1.2.3in Ihrem verwenden package.json, aber wie können Sie sicherstellen, dass jedes Mal npm installdieselbe Version auf Ihrem Entwicklungscomputer und auf dem Build-Server abgerufen wird, insbesondere in diesen indirekten Abhängigkeitspaketen? Nun, package-lock.jsonwird das sicherstellen. (Mit deren Hilfe werden npm ciPakete basierend auf der Sperrdatei installiert)
2. Es verbessert den Installationsprozess.
3. Es hilft bei der neuen Überwachungsfunktion npm audit fix(ich denke, die Überwachungsfunktion stammt aus npm Version 6).

Ich habe diese Datei nicht in meinen Projekten festgeschrieben. Was ist der Punkt ?

1. Es wird generiert
2. Dies ist die Ursache für einen SHA1-Code-Integritätsfehler in gitlab mit gitlab-ci.yml-Builds

Obwohl es wahr ist, dass ich ^ in meinem package.json nie für Bibliotheken verwende, weil ich schlechte Erfahrungen damit gemacht habe.

An die Leute, die sich über den Lärm beschweren, wenn sie Git Diff machen:

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

Ich habe einen Alias ​​verwendet:

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

Um package-lock.json in diffs für das gesamte Repository (alle, die es verwenden) zu ignorieren, können Sie dies hinzufügen .gitattributes :

package-lock.json binary
yarn.lock binary

Dies führt zu Unterschieden, die "Binärdateien a / package-lock.json und b / package-lock.json unterscheiden sich, wenn die Paketsperrdatei geändert wurde. Außerdem werden einige Git-Dienste (insbesondere GitLab, aber nicht GitHub) ebenfalls ausgeschlossen Diese Dateien (keine weiteren 10.000 Zeilen geändert!) stammen aus den Unterschieden, wenn Sie dies online anzeigen.

Ja, Sie können diese Datei festschreiben. Aus den offiziellen Dokumenten des npm :

package-lock.jsonwird automatisch für alle Vorgänge generiert, bei denen npmentweder der node_modulesBaum oder geändert wird package.json. 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.

Deaktivieren Sie package-lock.json global

Geben Sie Folgendes in Ihr Terminal ein:

npm config set package-lock false

Das funktioniert bei mir wirklich wie Magie

Ja, es ist eine Standardpraxis, package-lock.json festzuschreiben

Der Hauptgrund für das Festschreiben von package-lock.json ist, dass sich alle im Projekt auf derselben Paketversion befinden.

Vorteile: -

• Wenn Sie die strikte Versionierung befolgen und nicht zulassen, dass die Aktualisierung auf Hauptversionen automatisch erfolgt, um sich vor rückwärts inkompatiblen Änderungen in Paketen von Drittanbietern zu schützen, hilft das Festschreiben der Paketsperre sehr.
• Wenn Sie ein bestimmtes Paket aktualisieren, wird es in package-lock.json aktualisiert, und jeder, der das Repository verwendet, wird auf diese bestimmte Version aktualisiert, wenn er Ihre Änderungen übernimmt.

Nachteile: -

• Es kann dazu führen, dass Ihre Pull-Anfragen hässlich aussehen :) '

Bearbeiten: - Die npm-Installation stellt nicht sicher, dass sich alle im Projekt auf derselben Paketversion befinden. npm ci wird dabei helfen.

Meine Verwendung von npm ist das Generieren von minimierten / uglifizierten CSS / JS und das Generieren des Javascript, das auf Seiten benötigt wird, die von einer Django-Anwendung bereitgestellt werden. In meinen Anwendungen wird Javascript auf der Seite ausgeführt, um Animationen zu erstellen, manchmal Ajax-Aufrufe auszuführen, innerhalb eines VUE-Frameworks zu arbeiten und / oder mit dem CSS zu arbeiten. Wenn package-lock.json eine übergeordnete Kontrolle darüber hat, was in package.json enthalten ist, muss möglicherweise eine Version dieser Datei vorhanden sein. Nach meiner Erfahrung hat dies entweder keinen Einfluss darauf, was von npm install installiert wird, oder, falls dies der Fall ist, hat es die Anwendungen, die ich nach meinem Wissen bereitstelle, bisher nicht beeinträchtigt. Ich benutze keine Mongodb oder andere solche Anwendungen, die traditionell Thin Client sind.

Ich entferne package-lock.json aus dem Repo, da die npm-Installation diese Datei generiert und die npm-Installation Teil des Bereitstellungsprozesses auf jedem Server ist, auf dem die App ausgeführt wird. Die Versionskontrolle von Node und Npm erfolgt manuell auf jedem Server, aber ich bin vorsichtig, dass sie gleich sind.

Wenn npm installes auf dem Server ausgeführt wird, ändert es package-lock.json. Wenn Änderungen an einer Datei vorgenommen werden, die vom Repo auf dem Server aufgezeichnet wird, können Sie bei der nächsten Bereitstellung WONT keine neuen Änderungen vom Ursprung abrufen. Das heißt, Sie können nicht bereitstellen, da der Pull die Änderungen überschreibt, die an package-lock.json vorgenommen wurden.

Sie können eine lokal generierte package-lock.json nicht einmal mit dem auf dem Repo befindlichen Element überschreiben (Hard Origin Master zurücksetzen), da sich npm bei jeder Ausgabe eines Befehls beschwert, wenn die package-lock.json nicht den Inhalt widerspiegelt node_modules aufgrund der Installation von npm, wodurch die Bereitstellung unterbrochen wird. Wenn dies darauf hinweist, dass geringfügig andere Versionen in node_modules installiert wurden, hat mir dies wiederum nie Probleme bereitet.

Wenn sich node_modules nicht in Ihrem Repo befindet (und dies auch nicht sein sollte), sollte package-lock.json ignoriert werden.

Wenn mir etwas fehlt, korrigieren Sie mich bitte in den Kommentaren, aber der Punkt, an dem die Versionierung aus dieser Datei übernommen wird, macht keinen Sinn. Die Datei package.json enthält Versionsnummern, und ich gehe davon aus, dass diese Datei zum Erstellen von Paketen verwendet wird, wenn die npm-Installation erfolgt. Wenn ich sie entferne, beschwert sich die npm-Installation wie folgt:

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

und der Build schlägt fehl. Wenn Sie jedoch node_modules installieren oder npm zum Erstellen von js / css anwenden, wird keine Beschwerde eingereicht, wenn ich package-lock.json entferne

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...