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

1395

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.

rink.attendant.6
quelle
20
Kurze Antwort: ja. Ein Kommentar: Wenn sich package-lock.json ändert, können Sie genau diese Änderung festschreiben, getrennt von anderen Quelländerungen. Dies git logerleichtert den Umgang.
Purplejacket
14
Eine Datei kann nicht dazu beitragen, eine deterministische Installation zu erstellen, wenn sie nicht vorhanden ist.
Alan H.
4
Kommt auf das Projekt an. github.com/npm/npm/issues/20603
Gajus
3
Wenn Sie npm wirklich vertrauen, besteht der Zweck darin, expliziter zu berichten, was das Projekt verwendet. Wenn Sie wirklich Vorhersehbarkeit wünschen, ignorieren Sie diese Datei und installieren Sie stattdessen Ihre node_modules (siehe .npmrc und die zugehörige Konfiguration in den Antworten + Kommentar) und verwenden Sie diese, um zu verfolgen, was sich tatsächlich ändert, anstatt was Ihr Paketmanager angibt. Letztendlich: Was ist wichtiger? Ihr Paketmanager oder der von Ihnen verwendete Code.
Jimmy

Antworten:

1616

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.

Vine77
quelle
77
In welchen Projekten ist es tatsächlich hilfreich, die Datei festzuschreiben? Der springende Punkt bei semver und package.json ist, dass aktualisierte kompatible Abhängigkeiten nicht beachtet werden müssen.
neugierigdannii
45
Das Schlüsselwort ist "sollte nicht sein müssen" - aber in der Praxis folgen die Leute Semver nicht perfekt. Aus diesem Grund können Sie package-lock.json und package.json zusammen verwenden, um das Aktualisieren von Paketen zu vereinfachen und gleichzeitig sicherzustellen, dass jeder Entwickler und jede bereitgestellte Anwendung denselben Abhängigkeitsbaum verwenden.
Panu Horsmalahti
34
@trusktr: Sindre Sorhus empfiehlt die Verwendung von "Sperrdateien für Apps, aber nicht für Pakete".
Vine77
23
Eine andere Sache ist, dass package-lock.json für die Veröffentlichung auf NPM ignoriert wird. Wenn ein Entwickler es also für einen Bibliotheksentwickler verwendet, minimiert er die Wahrscheinlichkeit, dass er eine Regression von einer aktualisierten Abhängigkeitsversion abfängt, und besteht diese daher Fehler auf Endbenutzer. Aus diesem Grund erhöht die Nichtverwendung einer Sperrdatei für Bibliotheksentwickler die Wahrscheinlichkeit, dass weniger Fehler versendet werden.
Trusktr
128
Persönlich musste ich jetzt package-lock.jsonauf meine .gitignore... zurückgreifen. Es verursachte mir weit mehr Probleme als sie zu lösen. Es kommt immer zu Konflikten, wenn wir zusammenführen oder neu aufbauen, und wenn eine Zusammenführung dazu führt, package-lock.jsondass der CI-Server beschädigt wird, ist es nur ein Schmerz, das Problem weiterhin beheben zu müssen.
Stefan Z Camilleri
111

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.

xer0x
quelle
19
Es ist fair zu diskutieren, ob es in Ihr Quellcode-Repository eingecheckt werden soll, aber das Veröffentlichen dieser Datei in npm steht nicht wirklich zur Debatte - Sie müssen entweder Ihre package-lock.json- oder Ihre Shrinkwrap-Datei in Ihre npm-Registrierung aufnehmen. Wenn Sie dies nicht tun, unterliegt Ihr veröffentlichtes Paket nicht fixierten Änderungen der Abhängigkeiten Ihrer Abhängigkeiten der 1. Generation. Sie werden nicht bemerken, dass dies ein Problem ist, bis eine dieser Abhängigkeiten der 2. Generation eine wichtige Änderung veröffentlicht und Ihr veröffentlichtes Paket auf mysteriöse Weise beschädigt wird. Diese package-lock.json-Datei wurde erstellt, um dieses Problem zu lösen.
Guerillapresident
9
@BetoAveiga mit Rauschen Ich meine, dass die Commits mit package-lock.json so viele Zeilen mit Knotenpaketversionen haben können, dass jede andere Arbeit in diesem Commit ausgeblendet wird.
xer0x
7
Normalerweise halte ich Paketinstallationen von anderen Arbeiten getrennt. Ich muss ein Commit wie "Installed Chai and Mocha" nie ändern, weil ich bereits weiß, was sich geändert hat.
Keith
3
Irgendwelche Ratschläge bezüglich der package-lock.jsonDatei, wenn Sie an einem SCM-System mit Amtsleitungen und Verzweigung arbeiten? Ich nehme einige Änderungen an einem Zweig vor, die zum Trunk zusammengeführt werden müssen. Muss ich jetzt (irgendwie) Konflikte zwischen den beiden package-lock.jsonDateien lösen ? Das fühlt sich schmerzhaft an.
kmiklas
3
@ Guerillapresident Soweit ich weiß, haben Sie teilweise Recht. Die Veröffentlichung dieser Datei auf npm steht nicht zur Debatte. Sie können es nicht veröffentlichen.
Tim Gautier
66

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

k0pernikus
quelle
10
Diese Antwort verdient mehr Anerkennung, insbesondere mit npm ci. Durch diese Verwendung werden die meisten Probleme gemindert, die bei der Paketsperre aufgetreten sind.
JamesB
Ich habe festgestellt, dass die Verwendung einer festen Version in package.json (kein Caret oder Tilde) eine viel sauberere Option ist. Dies erspart mir whose build would fail one day because a random dependency got a breaking updateProbleme. Es bleibt jedoch die Möglichkeit, dass die Abhängigkeit des Kindes das gleiche Problem verursacht.
Ashwani Agarwal
58

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).
Xin
quelle
3
Soweit ich weiß, sollte die Verwendung von Semver (die npm-Entwickler sowieso nicht verstehen) zumindest in 99% der Fälle das gleiche Verhalten wie eine Sperrdatei ergeben. Meine eigene Erfahrung ist, dass Semver-Fuckups meistens mit Primärpaketen auftreten (direkte Abhängigkeiten, beschissene JQuery-Datepicker usw.). Meine persönliche Erfahrung mit npm war, dass Sperrdateien für immer Rauschen waren. Ich hoffe, dass diese Weisheit mit den neuesten Versionen unverändert bleibt.
Svend
13
+1 für die Erwähnung npm ci. Die Leute erwähnen häufig, dass a package-lock.jsoneine deterministische Installation von Paketen erlaubt, erwähnen aber fast nie den Befehl, der dieses Verhalten erleichtert! Viele Leute gehen wahrscheinlich fälschlicherweise davon aus, dass npm installgenau das installiert wird, was in der Sperrdatei enthalten ist ...
ahaurat
npm ci ist nicht in npm 5.
dpurrington
Vielen Dank! Es ist nur sinnvoll, package-lock.json festzuschreiben, wenn Sie verwenden npm ci. Ihr Team / leitender Entwickler kann entscheiden, wann ein Update durchgeführt werden soll. Wenn jeder es nur willkürlich festlegt, hat das keinen Sinn und es erzeugt nur Lärm in Ihrem Repo. Die NPM-Dokumentation sollte dies klarer machen. Ich denke, die meisten Entwickler sind nur durch diese Funktion verwirrt.
Adampasz
@adampasz Tatsächlich kann jeder Entwickler die Sperrdatei festschreiben. Sobald der Test bestanden und zusammengeführt wurde, erneuert der zweite Zweig die Sperrdatei, wenn die Pakete irgendwie geändert werden (wir ändern die package.json nicht oft, wir sind weniger mit diesem Problem konfrontiert ()
Xin
38

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.

Deunz
quelle
11
Ich wünschte, dies könnte in npm-Dokumenten näher erläutert werden. Es wäre nützlich, einen Überblick darüber zu haben, was Sie speziell verlieren, wenn Sie sich nicht festlegen package-lock.json. Einige Repos erfordern möglicherweise nicht die Vorteile, die sich daraus ergeben, und ziehen es möglicherweise vor, keine automatisch generierten Inhalte in der Quelle zu haben.
PotatoFarmer
2
Ich kann sehen, wie nützlich es für das Debuggen sein kann (ein Unterschied zwischen zwei Sperren zum Beispiel), um Probleme zu lösen. Ich denke, es kann auch verwendet werden, um solche Dinge zu verhindern, aber es kann auch schmerzhaft sein, es in einem gemeinsamen Repo zu haben, wo es aufgrund dessen zu Zusammenführungskonflikten kommen kann. Für den Anfang möchte ich die Dinge einfach halten. Ich werde package.json nur alleine verwenden, bis ich sehe, dass die package-lock.json wirklich benötigt wird.
Radtek
6
Sie können ^ in Ihrer package.json nicht verwenden, aber Sie können sicher sein, dass Ihre Abhängigkeiten es nicht verwenden?
Neiker
35

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.

Raza
quelle
1
Ich habe gd() { git diff --color-words $1 $2 -- :!/yarn.lock :!/package-lock.json; }in meinem .bashrc anstelle eines Alias.
apostl3pol
16

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.

Bablu Singh
quelle
13
Wird bei einer Installation nicht immer node_modules aktualisiert und daher package-lock.json aktualisiert?
Tim Gautier
2
Nein, Sie können die npm ciInstallation von package-lock.json
William Hampshire
Sie müssen in Ihrer Antwort betonen, dass Sie npm ci in Ihrem Build für die kontinuierliche Integration verwenden MÜSSEN, wenn Sie package-lock.json auf dem Repo haben
MagicLAMP
6

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

Balogun Ridwan Ridbay
quelle
2
dies schafft ~/.npmrc(zumindest auf meinem Mac OS) mit Inhalt package-lock=falseund das gleiche kann in einem bestimmten Projekt neben erfolgen node_modules/(zBecho 'package-lock=false' >> .npmrc
jimmont
6
Es ist irgendwie komisch für mich, dass dies negativ wäre. Die npm-Community kann einfach nicht akzeptieren, dass die automatische Generierung von package-lock.json eine schlechte Beteiligung der Community war. Sie sollten keine Dinge tun, die sich auf den Prozess eines Teams auswirken können. Es sollte eine Option zum Aktivieren und nicht zum Erzwingen gewesen sein. Wie viele Leute machen einfach "git add *" und bemerken es nicht einmal und vermasseln Builds. Wenn Sie einen auf Zusammenführung basierenden Fluss haben, weiß ich, dass Git-Fluss für die Leute, die ihn verwenden, wie die Bibel ist. Dies wird nicht funktionieren. Sie können keine Generation beim Zusammenführen haben! Die npm-Versionierung ist fehlerhaft, Paket: 1.0.0 sollte deterministisch sein!
Eric Twilegar
3
Warum wird das abgelehnt? Dies ist eindeutig eine legitime Methode zum Deaktivieren einer Funktion, die nicht funktioniert. Und obwohl es die Frage an sich nicht beantwortet, diskutiert es die Frage. dh es muss nicht mehr beantwortet werden. Daumen hoch von mir :)
Superole
Der Grund, warum es herabgestuft wird, ist, dass Sie einfach eine Funktion deaktivieren.
Raza
5

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.

Nikhil Mohadikar
quelle
4
Die Nachteile würden verschwinden, wenn Sie npm cistattdessen verwenden würden npm install.
k0pernikus
2
Scope kriecht ein wenig, aber hier sind weitere Informationen zu diesem ausgezeichneten Rat von @ k0pernikus .
Ruffin
1
"Jeder im Projekt wird auf der gleichen Paketversion sein, alles was Sie tun müssen, ist npm install" Nicht wahr, Sie müssen stattdessen "npm ci" verwenden
reggaeguitar
Danke, @reggaeguitar. Aktualisiere meine Antwort darauf.
Nikhil Mohadikar
2

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 ...
Magische Lampe
quelle
Um es hinzuzufügen, ich habe jetzt meine package-lock.json in mein Repository übernommen und verwende npm ci für meine ansible-Bereitstellung, von der ich glaube, dass sie die node_modules von delete löscht, und installiere alles in package-lock.json, ohne es zu aktualisieren. Auf diese Weise kann mein Front-End-Mitarbeiter Javascript aktualisieren, ohne dass manuelle Eingriffe in die Bereitstellung erforderlich sind.
MagicLAMP