it-swarm.com.de

Übertrage ich die von npm 5 erstellte Datei package-lock.json?

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

Soll diese Datei in der Quellcodeverwaltung aufbewahrt werden?

Ich gehe davon aus, dass es yarn.lock und composer.lock ähnelt, die beide in der Quellcodeverwaltung bleiben sollen.

1074

Ja, _package-lock.json_ soll 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._ Entsprechend npm help 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 die genaue Struktur, die generiert wurde, sodass nachfolgende Installationen unabhängig von zwischenzeitlichen Abhängigkeitsaktualisierungen identische Strukturen generieren können.

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

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

  • Bieten Sie Benutzern die Möglichkeit, in frühere Status von _node_modules_ zu "reisen", ohne das Verzeichnis selbst festschreiben zu müssen.

  • Um eine bessere Sichtbarkeit von Baumänderungen durch lesbare Versionskontrolldifferenzen zu ermöglichen.

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

Ein wichtiges Detail von _package-lock.json_ ist, 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, aber die Veröffentlichung ermöglicht. Dies wird nur empfohlen, wenn ein CLI-Tool bereitgestellt oder der Veröffentlichungsprozess zum Erstellen von Produktionspaketen anderweitig verwendet wird.

Wenn sowohl _package-lock.json_ als auch _npm-shrinkwrap.json_ im Stammverzeichnis eines Pakets vorhanden sind, wird _package-lock.json_ vollständig ignoriert.

1292
vine77

Ja, es soll eingecheckt werden. Ich möchte vorschlagen, dass es ein eigenes eindeutiges Commit erhält. Wir stellen fest, dass es unseren Diffs viel Lärm verleiht.

95
xer0x

Ja, am besten einchecken (JA, EINCHECKEN)

Ich bin damit einverstanden, dass es beim Betrachten des Unterschieds zu viel Lärm oder Konflikten kommt. Aber die Vorteile sind:

  1. garantiert genau die gleiche Version jedes Pakets. Dieser Teil ist der wichtigste beim Bauen in unterschiedlichen Umgebungen zu unterschiedlichen Zeiten. Sie können ^1.2.3 in Ihrem package.json verwenden, aber wie können Sie sicherstellen, dass jedes Mal npm install auf Ihrem Entwicklungscomputer und auf dem Buildserver dieselbe Version abruft, insbesondere bei diesen indirekten Abhängigkeitspaketen? Nun, package-lock.json wird das sicherstellen. (Mit Hilfe von npm ci, das Pakete basierend auf der Sperrdatei installiert)
  2. es verbessert den Installationsprozess.
  3. es hilft mit der neuen Audit-Funktion npm audit fix (Ich denke, die Audit-Funktion ist von npm Version 6).
46
Xin

Ich lege diese Datei in meinen Projekten nicht fest. 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 nie ^ in meiner package.json für libs verwende, weil ich schlechte Erfahrungen damit gemacht habe :)

Grüße.

30
Deunz

An die Leute, die sich über den Lärm beim Git Diff beschweren:

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 (jeder, der es verwendet) zu ignorieren, können Sie dies zu .gitattributes hinzufügen:

package-lock.json binary
yarn.lock binary

Dies führt zu Unterschieden, die anzeigen, dass sich die Binärdateien a/package-lock.json und b/package-lock.json unterscheiden, wenn die Paketsperrdatei geändert wurde. Darüber hinaus werden einige Git-Dienste (insbesondere GitLab, aber nicht GitHub) ebenfalls ausgeschlossen Diese Dateien (keine weiteren 10k Zeilen geändert!) werden beim Online-Betrachten von den Unterschieden entfernt, wenn Sie dies tun.

26
Raza

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

package-lock.json wird automatisch für alle Vorgänge generiert, bei denen npm entweder den node_modules -Baum oder package.json ändert. Es beschreibt die genaue Struktur, die generiert wurde, sodass nachfolgende Installationen unabhängig von zwischenzeitlichen Abhängigkeitsaktualisierungen identische Strukturen generieren können.

Diese Datei soll in Quell-Repositorys [.] Geschrieben werden

15
Bablu Singh

Ja du solltest:

  1. beende den package-lock.json.
  2. Verwenden Sie npm ci anstelle von npm install, wenn Sie Ihre Anwendungen sowohl auf Ihrem CI als auch auf Ihrem lokalen Entwicklungscomputer erstellen

Der Workflow npm ci erfordert die Existenz eines package-lock.json.

Ein großer Nachteil des Befehls npm install ist das unerwartete Verhalten, dass der Befehl package-lock.json möglicherweise mutiert, wohingegen npm ci nur die in der Sperrdatei angegebenen Versionen verwendet und einen Fehler erzeugt, wenn der Befehl package-lock.json und package.json sind nicht synchron oder wenn ein package-lock.json fehlte.

Daher wird npm install lokal ausgeführt, insb. In größeren Teams mit mehreren Entwicklern kann es zu vielen Konflikten innerhalb des package-lock.json kommen, und Entwickler entscheiden sich stattdessen, den package-lock.json vollständig zu löschen.

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

Aus einem package-lock.json erhalten Sie genau das: einen Arbeitsstatus, der bekannt ist.

In der Vergangenheit hatte ich Projekte ohne package-lock.json/npm-shrinkwrap.json/yarn.lock -Dateien, deren Erstellung eines Tages fehlschlagen würde, weil eine zufällige Abhängigkeit ein fehlerhaftes Update bekam.

Diese Probleme sind schwer zu lösen, da Sie manchmal raten müssen, welche Version zuletzt funktioniert hat.

Wenn Sie eine neue Abhängigkeit hinzufügen möchten, führen Sie weiterhin npm install {dependency} aus. Wenn Sie ein Upgrade durchführen möchten, verwenden Sie entweder npm update {dependency} oder npm install ${dependendency}@{version} und übernehmen Sie den geänderten package-lock.json.

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


An Zitat npm doc :

Es wird dringend empfohlen, die generierte Paketsperre der Quellcodeverwaltung zuzuweisen. Dadurch können alle Mitglieder Ihres Teams, Ihre Bereitstellungen, Ihre CI-/Continuous-Integration und alle anderen Benutzer, die npm install in Ihrer Paketquelle ausführen, denselben Abhängigkeitsbaum abrufen das du weiterentwickelt hast. Darüber hinaus sind die Unterschiede zu diesen Änderungen für den 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, gehisst usw. wurden.

Und in Bezug auf die nterschied zwischen npm ci vs npm install :

  • Das Projekt muss über eine vorhandene package-lock.json- oder npm-shrinkwrap.json-Datei verfügen.
  • Wenn die Abhängigkeiten in der Paketsperre nicht mit denen in package.json übereinstimmen, wird npm ci mit einem Fehler beendet, anstatt die Paketsperre zu aktualisieren.
  • npm ci kann nur ganze Projekte gleichzeitig installieren. Einzelne Abhängigkeiten können mit diesem Befehl nicht hinzugefügt werden.
  • Wenn bereits ein node_modules vorhanden ist, wird dieser automatisch entfernt, bevor npm ci mit der Installation beginnt.
  • Es wird niemals in package.json oder eine der Paketsperren geschrieben: Installationen sind im Wesentlichen eingefroren.

Hinweis: Ich habe eine ähnliche Antwort gepostet hier

10
k0pernikus

Deaktiviere package-lock.json global

geben Sie Folgendes in Ihr Terminal ein:

npm config set package-lock false

das funktioniert für mich wirklich wie Zauberei

Ja, das Festschreiben von package-lock.json ist Standard

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

Vorteile: -

  • Jeder in dem Projekt wird die gleiche Paketversion haben, alles was Sie tun müssen, ist

    npm install

  • Wenn Sie die strikte Versionsverwaltung einhalten und das automatische Aktualisieren auf Hauptversionen nicht zulassen, um sich vor inkompatiblen Änderungen in Paketen von Drittanbietern zu schützen, hilft das Festschreiben einer Paketsperre erheblich.

Nachteile: -

  • Es kann Ihre Pull-Anfragen hässlich aussehen lassen :) '
2

Ich benutze npm, um minimierte/uglifizierte CSS/JS zu generieren und das Javascript zu generieren, das für 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 über package.json hat, ist möglicherweise eine Version dieser Datei erforderlich. Nach meiner Erfahrung hat dies entweder keinen Einfluss darauf, was von npm install installiert wird, oder, falls dies der Fall ist, hat sich dies bislang nicht nachteilig auf die von mir bereitgestellten Anwendungen ausgewirkt. Ich verwende kein Mongodb oder andere solche Anwendungen, die traditionell Thin Clients sind.

Ich entferne package-lock.json aus repo, weil npm install diese Datei generiert und npm install 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 achte darauf, dass sie gleich sind.

Wenn npm install auf dem Server ausgeführt wird, ändert sich package-lock.json. Wenn Änderungen an einer Datei vorgenommen werden, die vom Repository auf dem Server aufgezeichnet wurde, können Sie mit der nächsten Bereitstellung keine neuen Änderungen aus Origin abrufen . Das heißt, Sie können keine Bereitstellung durchführen, da durch den Pull die an package-lock.json vorgenommenen Änderungen überschrieben werden.

Sie können nicht einmal eine lokal generierte package-lock.json mit dem Inhalt des Repos überschreiben (harte Origin-Master zurücksetzen), da npm sich jedes Mal beschwert, wenn Sie einen Befehl ausgeben, 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 in node_modules etwas andere Versionen installiert wurden, hat mich das erneut nie zu Problemen geführt.

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

Wenn ich etwas vermisse, korrigieren Sie mich bitte in den Kommentaren, aber der Punkt, dass die Versionierung aus dieser Datei übernommen wird, macht keinen Sinn. In der Datei package.json sind Versionsnummern enthalten, und ich gehe davon aus, dass diese Datei zum Erstellen von Paketen verwendet wird, wenn npm install ausgeführt wird. Wenn ich sie entferne, beklagt sich npm install wie folgt:

[email protected]:introcart_wagtail$ rm package.json
[email protected]: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 erhoben, wenn ich package-lock.json entferne

[email protected]:introcart_wagtail$ rm package-lock.json 
[email protected]:introcart_wagtail$ npm run dev

> [email protected] dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

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