Dies ist nicht das, was ci/cleaninstall tun soll. Das aktuelle Verhalten ist korrekt. Was Sie verwenden möchten, ist npm shrinkwrap .

Wir haben ein Update hinzugefügt, um zu vermeiden, dass der _folder_ node_modules_ gelöscht wird, aber nicht sein _contents_ (wie ursprünglich in diesem Beitrag angefordert). Der Zweck des Befehls npm ci besteht darin, alles zu löschen, um von einer neuen Seite zu beginnen. Wenn Sie Ihre alten node_modules behalten möchten, benötigen Sie npm i .

Danke für eure Antworten! Sorry für meine späte Antwort. Ich habe mir npm shrinkwrap aber soll dies auf unserem Build-Server für die kontinuierliche Integration ausgeführt werden? Wenn dieser Befehl ausgeführt wird, benennt er mein package-lock.json in npm-shrinkwrap.json aber was soll ich dann während der CI ausführen? Nur npm install für ein inkrementelles Update? Oder sollte ich npm ci ausführen, aber das löscht alle Pakete wieder :-( Was ich suche, ist ein Befehl, der ein inkrementelles Update durchführt, aber genau das installiert, was in unserem package-lock.json

@claudiahdz; Ich verstehe, dass das Ausführen von npm install während der CI die package-lock.json aktualisiert und das könnte bedeuten, dass das Ausführen desselben Builds ein paar Wochen später verschiedene Pakete installieren würde. Ist das falsch?

Ps ich dachte, npm ci für Continuous Integration

Wie hier verwiesen: https://github.com/npm/npm/issues/20104#issuecomment -403321557

Das aktuelle Verhalten ist problematisch, wenn Sie npm ci innerhalb eines Docker-Containers verwenden (was bei Continuous Integration durchaus üblich ist) und Sie einen Bind-Mount auf node_modules

Es verursacht folgenden Fehler:

webpack_1   | npm ERR! path /var/www/project/docker-config/webpack-dev-devmode/node_modules
webpack_1   | npm ERR! code EBUSY
webpack_1   | npm ERR! errno -16
webpack_1   | npm ERR! syscall rmdir
webpack_1   | npm ERR! EBUSY: resource busy or locked, rmdir '/var/www/project/docker-config/webpack-dev-devmode/node_modules'

was dann zum Abbruch des Docker-Containers führt.

Es wäre schön, ein --no-delete Flag zu haben oder wenn npm ci den _contents_ von node_modules löschen könnte, aber nicht das Verzeichnis selbst.

ci = saubere Installation

Dies wird erwartet. Warum verwenden Sie nicht das normale npm i mit einer Lockfile?

Es wäre schön, ein --no-delete-Flag zu haben oder wenn npm ci den Inhalt von node_modules löschen könnte, aber nicht das Verzeichnis selbst.

rm -rf node_modules/* && npm i

ci = saubere Installation

Dies wird erwartet. Warum verwendest du nicht das normale npm i mit einer Lockfile?

...weil: https://docs.npmjs.com/cli/ci.html

Dieser Befehl ähnelt npm-install, ist jedoch für die Verwendung in automatisierten Umgebungen wie Testplattformen, Continuous Integration und Deployment gedacht – oder in jeder Situation, in der Sie sicherstellen möchten, dass Sie eine saubere Installation Ihrer Abhängigkeiten durchführen. Es kann erheblich schneller sein als eine normale npm-Installation, indem bestimmte benutzerorientierte Funktionen übersprungen werden. Es ist auch strenger als eine normale Installation, was dazu beitragen kann, Fehler oder Inkonsistenzen zu erkennen, die durch die inkrementell installierten lokalen Umgebungen der meisten npm-Benutzer verursacht werden.

Die schnelleren Installationen und der Clean Slate-Ansatz machen dies ideal für CI-Umgebungen wie die oben erwähnte.

rm -rf node_modules/* && npm i

Das mache ich jetzt, aber siehe oben für den Wunsch, npm ci

Es scheint mir vernünftig, einen RFC einzureichen, der nach einem Konfigurationsflag fragt, das npm ci , den Inhalt von node_modules und nicht das Verzeichnis selbst zu entfernen. Dies ist auch ein Problem für mich, da ich Dropbox so eingerichtet habe, dass ein node_modules -Verzeichnis selektiv ignoriert wird, aber wenn ich es lösche, verschwindet diese selektive Einstellung und das nächste Mal node_modules erstellt wird, wird es synchronisiert.

Es scheint mir vernünftig, einen RFC einzureichen, der nach einem Konfigurationsflag fragt, das npm ci , den _contents_ von node_modules und nicht das Verzeichnis selbst zu entfernen. Dies ist auch ein Problem für mich, da ich Dropbox so eingerichtet habe, dass ein node_modules -Verzeichnis selektiv ignoriert wird, aber wenn ich es lösche, verschwindet diese selektive Einstellung und das nächste Mal node_modules erstellt wird, wird es synchronisiert.

Ist dies nicht auch das, was ein anderes Problem beschrieben hat, damit npm Dateien erstellen kann, um das Verzeichnis zu ignorieren (für OSX-Spotlight und andere)? Ich denke, es gab auch andere, die diese Funktion brauchen.

ci = saubere Installation

Dies wird erwartet. Warum verwenden Sie nicht das normale npm i mit einer Lockfile?

npm i wäre großartig, aber nur, wenn es die Sperrdatei nicht ändern würde. Ich habe gesehen, dass die package-lock.json während eines npm i aktualisiert wurde oder sollte das nicht passieren?

Ich unterstütze diese Funktion. Wie bereits erwähnt, modifiziert npm i package-lock.json. Eine Flagge wäre die ideale Lösung.

genauso, eine flagge wäre toll

Ich unterstütze diese Funktion. Wie bereits erwähnt, modifiziert npm i package-lock.json. Eine Flagge wäre die ideale Lösung.

Warum dann nicht ein Flag für npm i hinzufügen? Denn das würde für ci = clean install in meinem Sinne nicht viel Sinn machen.

Welcher Teil der "sauberen Installation" ist nicht kompatibel damit, das übergeordnete Verzeichnis node_modules/ intakt zu halten (während eine saubere Installation des eigentlichen Inhalts durchgeführt wird)?

Mir ist klar, dass CI in diesem Fall nicht für Continuous Integration steht; aber eine saubere Installation ist in einer Continuous-Integration-Umgebung oft sehr nützlich, wie die Dokumentation deutlich macht.

Dieser Befehl ähnelt npm-install, ist jedoch für die Verwendung in automatisierten Umgebungen wie Testplattformen, Continuous Integration und Deployment gedacht – oder in allen Situationen, in denen Sie sicherstellen möchten, dass Sie eine saubere Installation Ihrer Abhängigkeiten durchführen. Es kann erheblich schneller sein als eine normale npm-Installation, indem bestimmte benutzerorientierte Funktionen übersprungen werden. Es ist auch strenger als eine normale Installation, was dazu beitragen kann, Fehler oder Inkonsistenzen zu erkennen, die durch die inkrementell installierten lokalen Umgebungen der meisten npm-Benutzer verursacht werden.

npm ci ist speziell für die Verwendung in automatisierten Umgebungen gedacht, oft bedeutet dies ein Docker-basiertes Setup.

Das Verhalten beim Löschen des node_module/ Verzeichnisses ist in einem Docker-basierten Setup aus den in diesem Thread genannten Gründen problematisch.

Wir fragen also nach einer Option, die diesen Befehl für seinen beabsichtigten Zweck und seine Umgebung nützlich macht.

Ich unterstütze diese Funktion. Wie bereits erwähnt, modifiziert npm i package-lock.json. Eine Flagge wäre die ideale Lösung.

Warum dann nicht ein Flag für npm i hinzufügen? Denn das würde für ci = clean install in meinem Sinne nicht viel Sinn machen.

Ich habe diese Frage stellen ihre weiteren Unterschiede zwischen npm install und npm ci , wenn nicht , warum dann nicht beiden Optionen in npm install vielleicht ci Bedürfnissen ein Deckname wie npm install --no-update-package-lock --clean-node-modules

Das Verhalten beim Löschen des Verzeichnisses node_module/ ist in einem Docker-basierten Setup aus den in diesem Thread genannten Gründen problematisch.

Meiner Meinung nach sollte dies nur einmal passieren, wenn das Image erstellt wird. Danach sollte npm i während der Entwicklung verwendet werden.

vielleicht muss ci ein Alias ​​werden wie npm install --no-update-package-lock --clean-node-modules

Mir persönlich macht das mehr Sinn, zusätzliche Flags für den normalen npm i Befehl.

Mir ist es egal, was und ehrlich gesagt zu viel von einem n00b mit js, um ein konkretes Argument zu haben, dass es ci , ich weiß nur, dass es das package-lock.json nicht aktualisieren sollte und sollte node_modules nicht entfernen

npm ci aktualisiert die Sperrdatei nicht, es wird aus der Sperrdatei installiert. Dies wurde eingeführt, um eine saubere Installation durchzuführen, da diesen Leuten zuvor geraten wurde, rm -rf node_modules und npm i erneut auszuführen. Und afaik wollten die Leute, dass es die Lockfile nicht ändert, sondern von ihr installiert.

Also wurde npm ci geboren. Und es überspringt auch einige Dinge wie die Liste der installierten Pakete und den Baum und ein paar andere Dinge.

Siehe https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

Es deckt einen bestimmten Anwendungsfall ab.

Für andere Anwendungsfälle sollten wir neue Flags zu npm i hinzufügen, mit denen wir auch npm ci emulieren können, was eine flexiblere und bessere Lösung ist als Flags für npm ci die nur noch abdecken sollten der aktuelle Anwendungsfall imho. Was die Benutzer hier anfordern, ist yarn install --frozen-lockfile oder yarn --frozen-lockfile ähnlich.

Ansonsten werden Flags über npm ci , npm i usw. verteilt, was es etwas schwieriger macht (Dokumentation, Code, ...). Das denke ich zumindest. Lassen Sie es uns auf npm i setzen. Wir haben leistungsfähigere und flexiblere Möglichkeiten, sein Verhalten zu konfigurieren.

Für andere Anwendungsfälle sollten wir neue Flags zu npm i hinzufügen, mit denen wir auch npm ci emulieren können, was eine flexiblere und bessere Lösung ist als Flags für npm ci, die imho nur den aktuellen Anwendungsfall abdecken sollten. Was die Benutzer hier anfordern, ist ein bisschen ähnlich wie bei "garn install --frozen-lockfile" oder "garn --frozen-lockfile".

Ich würde mich sehr freuen, wenn die Funktion zu npm i hinzugefügt würde. Soll ich den ursprünglichen Beitrag aktualisieren?

npm ci aktualisiert die Sperrdatei nicht, es wird aus der Sperrdatei installiert. Dies wurde eingeführt, um eine saubere Installation durchzuführen, da diesen Leuten zuvor geraten wurde, rm -rf node_modules und npm i erneut auszuführen. Und afaik wollten die Leute, dass es die Lockfile nicht ändert, sondern von ihr installiert.

Also wurde npm ci geboren. Und es überspringt auch einige Dinge wie die Liste der installierten Pakete und den Baum und ein paar andere Dinge.

Siehe https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

Es deckt einen bestimmten Anwendungsfall ab.

Für andere Anwendungsfälle sollten wir neue Flags zu npm i hinzufügen, mit denen wir auch npm ci emulieren können, was eine flexiblere und bessere Lösung ist als Flags für npm ci die nur noch abdecken sollten der aktuelle Anwendungsfall imho. Was die Benutzer hier anfordern, ist yarn install --frozen-lockfile oder yarn --frozen-lockfile ähnlich.

Inwiefern gilt rm -rf node_modules/* nicht als "Reinigung"? Die hier gefragte Funktion ist der in npm ci sehr ähnlich. Meiner Meinung nach ist es sinnvoller, npm ci ein Flag hinzuzufügen, damit es rm -rf node_modules/* anstelle von rm -rf node_modules anstatt das gesamte Verhalten von npm ci in npm i zu importieren.

Übrigens sollte diesem Thema mehr Aufmerksamkeit gewidmet werden und Betreuer sollten ihre Meinungen und Pläne dazu äußern, die Verwendung von Docker wird grundsätzlich immer in CI (Continuous Integration) verwendet, was einer der Hauptanwendungsfälle von npm ci ist!

Bitte öffnen Sie einen RFC für diese Änderung und nicht für ein Problem in diesem Repository.

Um Verwirrung zu vermeiden, würde ich dieses Problem in „leer statt node_modules dir in npm CI entfernen“ umbenennen.

Meine Absicht bei diesem Problem war nie, den Ordner node_modules oder nur seinen Inhalt zu löschen. Es ging immer darum, den Inhalt von node_modules beizubehalten, aber sicherzustellen, dass er aktuell und mit package-lock.json synchronisiert ist. Also ein inkrementelles Update, das sich an die package-lock.json .

Vielleicht liege ich falsch, aber ich habe das Gefühl, dass es hier zwei Probleme gibt. Vielleicht könnte jemand ein anderes Problem oder RFC starten, um nur den Inhalt von node_modules zu löschen, anstatt den Ordner vollständig zu löschen? Oder übersehe ich etwas?

@Zenuka Der gesamte Grund, warum npm CI schnell ist und existiert, liegt darin, dass es das vorhandene node_modules-Verzeichnis ignoriert. Es ist also ziemlich unwahrscheinlich, dass sich das ändert.

In unserem Anwendungsfall denke ich, dass es schneller wäre, nur zu überprüfen, ob der Ordner nodes_modules auf dem neuesten Stand ist oder nicht. Und wenn es nicht, nur die Pakete aktualisieren , die aktualisiert werden soll (wie npm i der Fall ist) Ich habe einige dedizierte VM ausgeführt wird als Build - Agenten so ein Build ausgeführt wird und die halten nodes_modules Ordner und all seinen Inhalt Sollte schneller gehen als alles zu löschen und neu zu installieren. Wir führen unseren Build und Tests auf Codeänderungen viel mehr aus als Änderungen an unseren package.json oder package-lock.json .

In unserem Anwendungsfall denke ich, dass es schneller wäre, nur zu überprüfen, ob der Ordner nodes_modules auf dem neuesten Stand ist oder nicht.

Nun, dies (die Berechnung des Paketbaums) nimmt die meiste Zeit in Anspruch. Diese Prüfung würde npm ci wirklich langsam machen.

einen Build auszuführen und den Ordner nodes_modules und seinen gesamten Inhalt beizubehalten, sollte schneller sein, als alles zu löschen und neu zu installieren.

Wahrscheinlich nicht, deshalb wurde npm ci eingeführt, das überspringt, was npm i tut (siehe Paketbaum).

@Zenuka npm install bereits der schnellste Weg, um das zu tun, was Sie wollen. npm ci hat nur einen Zweck: es schneller zu machen, indem es node_modules löscht, damit es kein Diff berechnen muss.

Wahrscheinlich nicht, deshalb wurde npm ci eingeführt, das überspringt, was npm i tut (siehe Paketbaum).

Ich habe dies nur auf meinem Computer getestet (was natürlich keine gute Maßnahme ist), aber das Ausführen von npm install auf einem aktuellen node_modules Ordner endet innerhalb von 10 Sekunden. Das Ausführen von npm ci dauert Minuten. Würden Sie andere Ergebnisse erwarten?

Ich bin ein Fan Ihres Vorschlags , ein Flag hinzuzufügen, um die Sperrdatei mit npm install einzufrieren.

Die Überprüfung, ob das, was in package-lock.json steht, tatsächlich vorhanden ist, ist selbst unter Windows superschnell. Siehe https://github.com/fuzzykiller/verify-node-modules.

Die Überprüfung, dass in node_modules nichts anderes vorhanden ist, würde sicherlich etwas länger dauern, aber wahrscheinlich immer noch weniger als eine Sekunde.

Auf dieser Grundlage könnte leicht eine inkrementelle Version von npm ci erstellt werden. Immerhin ist der Baum bereits berechnet und in package-lock.json gespeichert.

Außerdem besteht der einzige Grund npm ci , das zu installieren, was in package-lock.json . Ohne Überraschungs-Upgrades einzuschleusen, wie es npm install tut.

nur meine 2 Cent, ich persönlich habe unsere Infra auf npm ci umgestellt, da ich es auch satt hatte, ein altes Tag zu implementieren, npm i würde sich nicht an die Sperrdatei halten ... also wenn es ernst ist? so groß ein Problem der Flagge am hinzuzufügen npm ci Niveau (was ich .. its bekommen clean install ihre zu tun , was seine gesagt) , dann npm i REALLLLLYLYY dieses Flag muss. aber ich erinnere mich, dass ich das recherchiert habe und es gab auch einen Thementhread zu npm i , der über 2 Jahre alt (und immer noch offen) war, in dem das npm-Team vorschlug, dass die Leute npm ci ist irgendwie der Grund, warum die Leute in der Vergangenheit npm aufgegeben und einfach zu Garn gegangen sind.

wieder nur eine andere devs-Perspektive

Ich stimme für das Hinzufügen der Möglichkeit, die Module zu behalten :heavy_plus_sign: .

+1 hier - wie @phyzical und @fuzzykiller sagten, gibt es keinen "Sweet Spot" zwischen npm install und npm ci , der node_modules BEHÄLT, aber trotzdem package-lock.json respektiert und schneller läuft.
Führen Sie einfach so schnell wie möglich aus - suchen Sie nach Abhängigkeiten von Paketsperren, die bereits in node_modules vorhanden sind, und installieren Sie dann alles andere, was fehlt.. keine Upgrades, kein Löschen.

Persönlich ist es mir egal, welches das ist ( install oder ci ), das das haben würde, aber das alles klingt so, als ob npm install nur Flags für alles haben sollten und npm ci muss kein separater Befehl sein.

Dies ist etwas frustrierend, da npm ci ursprünglich als Lösung für das gleiche Problem angepriesen wurde, das dieses Problem aufwirft.

Das ursprüngliche Verhalten, das einige Leute für npm install wollten, war, sich package-lock.json statt package.json anzusehen. Wir wollten ein Flag auf npm install , um dieses Verhalten zu aktivieren. Stattdessen bekamen wir npm ci , weil:

Die package.json beschreibt die erforderlichen Abhängigkeiten Ihres Projekts. Wenn die aktuelle Sperrdatei diese nicht erfüllen kann, muss die Sperrdatei weichen. Der Zweck der Sperrdatei besteht darin, eine wiederholbare Installation auf verschiedenen Computern zu erstellen und nicht die package.json zu veralteten.

Also gut. npm install ist nicht der richtige Ort für diese Option, npm ci . Außer npm ci fügt zusätzliche Verhaltensweisen hinzu (Löschen des Ordners node_modules ), die verhindern, dass es eine nützliche Lösung für das ursprüngliche Problem ist. Und der Grund, warum npm ci jetzt nicht markiert werden kann, ist folgender:

ci = saubere Installation

Dies wird erwartet. Warum verwendest du nicht das normale npm i mit einer Lockfile?

Was... in Ordnung. Es ist mir egal, wo die Flagge hinzugefügt wird. Ich habe kein Interesse an der zugrunde liegenden Philosophie hinter der Schnittstelle. Aber könnte die Flagge bitte irgendwo hinzugefügt werden?

Verdammt, ich würde keine Einwände erheben, selbst wenn die Leute einen völlig separaten dritten Befehl wünschen, ist mir das egal. Das einzige, was mich interessiert, ist, dass 3 Jahre nachdem dieses Gespräch über die Achtung von package-lock.json für normale Installationen begonnen hat, es immer noch keine Möglichkeit gibt, das Verhalten zu erreichen, nach dem wir ursprünglich gefragt haben.

An meinem Arbeitsplatz haben wir Fehler von kleineren und Bugfix-Versionsupdates für Pakete gesehen. Wir wollen wirklich nur bei gezielten Paket-Upgrades nach diesen Fehlern suchen, wir möchten nicht, dass unsere Entwicklungsumgebungen andere Paketversionen verwenden als unsere Produktionsumgebungen. Konsistenz ist dort sehr wichtig. Wie auch immer irgendjemand es nennen möchte oder wo auch immer jemand es platzieren möchte, wir wollen einen schnellen Weg, um Pakete aus der Lockfile zu bekommen, die uns auch nicht jedes Mal erfordert, node-gyp Builds für bereits installierte Module durchzuarbeiten den Befehl ausführen.

So soll es in einer perfekten Welt funktionieren:

• npm install - gleiches Verhalten wie heute
• npm install --from-lockfile - Installation aus der Sperrdatei (wie ci )
• npm install --clean - gleiches Verhalten wie npm install aber den Inhalt von node_modules löschen
• npm ci - ein Alias ​​für npm install --from-lockfile --clean

@jdussouillez Genau das sollte passieren. Sehr gut gesagt! Ich würde mich freuen, wenn diese Lösung umgesetzt wird.

Es ist immer frustrierend, auf dieses Problem zu stoßen, bei dem wir uns zwischen Geschwindigkeit und Konsistenz für eine CI-Pipeline entscheiden müssen. Ich bin allein in den letzten 2 Monaten aus verschiedenen Gründen 3 oder 4 Mal darauf gestoßen.

Dieses Feature wäre ideal für Azure Pipelines und andere Cloudarchitekturen.

https://docs.microsoft.com/en-us/azure/devops/pipelines/release/caching?view=azure-devops#tip

Da npm ci den Ordner node_modules löscht, um sicherzustellen, dass ein konsistenter, wiederholbarer Satz von Modulen verwendet wird, sollten Sie beim Aufrufen von npm ci vermeiden, node_modules zwischenzuspeichern.

Schließen: Wie @claudiahdz erwähnt, haben wir dieses Verhalten npm ci nicht mehr den Ordner node_nodules selbst entfernt, sondern nur seinen Inhalt (ref. https://github.com/npm /libcipm/blob/latest/CHANGELOG.md#407-2019-10-09). Dies wurde am 21. Juli in [email protected] versendet (ref. https://github.com/npm/cli/blob/v6/CHANGELOG.md#6147-2020-07-21) und wir haben gewartet die gleiche Erfahrung in npm@7 .

Wenn Sie ein separates Problem mit npm ci oder einem anderen Befehl haben, verwenden Sie bitte eine unserer Problemvorlagen, um einen Fehler zu melden: https://github.com/npm/cli/issues/new/choose

Randnotizen...

@jdussouillez freut sich über das Feedback; Was die Installation direkt aus einer Lockfile angeht, können Sie dies heute mit dem Flag --package-lock-only (zB npm install --package-lock-only ) tun. In Bezug auf das Hinzufügen eines --clean Flags zu install habe ich nicht das Gefühl, dass dies viel Wert bringt, aber ich könnte mich irren. Wenn Sie sich dafür stark fühlen, würden wir uns freuen, wenn Sie einen RFC unter https://github.com/npm/rfcs einreichen

Der Kommentar von @claudiahdz vor fast einem Jahr scheint damit zusammenzuhängen, sicherzustellen, dass das Verhalten von npm ci besteht, den Inhalt von node_modules anstelle des Ordners selbst zu löschen. Was praktisch ist, wenn Sie es in einen Docker-Container einhängen (zum Beispiel), ändert aber immer noch nichts am Endergebnis - npm ci lädt alle Abhängigkeiten von Grund auf.

Die Verwendung von npm install --package-lock-only scheint das genaue Gegenteil von dem zu tun, worum es beim ursprünglichen Problem geht (wenn ich das richtig verstehe) - es aktualisiert nur die package-lock.json Datei und lädt keine Abhängigkeiten herunter.

Was ich aus dem ursprünglichen Problem verstehe, ist die Notwendigkeit, eine Option zu haben, die einen aktuellen Status des Ordners node_modules und eine package-lock.json Datei abruft und nur die erforderlichen Pakete herunterlädt, um die node_modules Versionen, die den package-lock.json . Es wird also viel schneller sein, als jedes Mal alles herunterzuladen, mit dem gleichen Nettoergebnis am Ende.

Ist das nicht schon immer das, was npm install tut?

Ist das nicht schon immer das, was npm install tut?

SO VIEL ICH WEISS -
npm install löst alle Abhängigkeiten gemäß der Datei package.json (ohne die package-lock.json ignorieren), vergleicht sie mit dem, was sich derzeit im Ordner node_modules , und lädt die Abhängigkeiten, die heruntergeladen werden müssen, um die Anforderungen zu erfüllen. Es wird auch die package-lock.json entsprechend aktualisieren.

Es ignoriert definitiv nicht die Lockfile - es berücksichtigt nur den vorhandenen Baum, was npm ci nicht tut.

Du hast recht, tut mir leid.
Ich habe mich falsch erinnert (vielleicht war das früher das Verhalten?). Habe gerade einige Tests mit einem einfachen dep-Baum durchgeführt, und wenn die Datei package-lock.json vorhanden ist, installiert npm i genau die Versionen, die es spezifiziert, und ändert nichts. Das war genau das Verhalten, nach dem ich gesucht habe, also bin ich damit zufrieden. 👍
Ich entschuldige mich für das Posten zu einem geschlossenen Thema.

Meine ursprüngliche Anfrage war tatsächlich das, was ATGardner beschreibt:

Was ich aus dem ursprünglichen Problem verstehe, ist die Notwendigkeit, eine Option zu haben, die einen aktuellen Status des Ordners node_modules und eine package-lock.json Datei abruft und nur die erforderlichen Pakete herunterlädt, um die node_modules Versionen, die den package-lock.json . Es wird also viel schneller sein, als jedes Mal alles herunterzuladen, mit dem gleichen Nettoergebnis am Ende.

Meine Erfahrung mit npm install ist, dass es manchmal die Datei package-lock.json aktualisiert. Ich habe dies heute Morgen erneut mit einem Repository getestet, das ich seit einiger Zeit nicht mehr aktualisiert hatte und das git pull und npm i . Es wurden diesmal keine Versionen aktualisiert, sondern nur einige Abhängigkeiten und zusätzliche Pakete hinzugefügt.

Leider ist dies ein privates Repository, aber vielleicht jemand anderes als reproduzierbares öffentliches Repository? Wenn es mehrere Commits gibt und das Umschalten zwischen ihnen dazu führt, dass npm install die package-lock.json aktualisiert?

Mir ist klar, dass es zu Benutzerfehlern kommen kann, wenn die package-lock.json beim Aktualisieren der package.json aber meine Kollegen wissen, dass sie auch die package-lock.json aktualisieren sollten. Ich werde das prüfen.

Ich konnte nicht mein einfaches Beispiel bekommen haben npm i das ändern package-lock.json Datei. Aber ich werde es noch etwas ausprobieren.

Wenn npm i immer genau die gleichen Versionen herunterlädt, die in package-lock.json , während sie so viel wie möglich von den aktuellen node_modules behalten, warum sollte ich dann jemals npm ci ausführen müssen

Siehe https://docs.npmjs.com/cli/v6/commands/npm-ci#description

Ich entschuldige mich noch einmal, dass dies nicht der Ort für diese Diskussion ist. Gibt es woanders besseres?

Ich verstehe immer noch nicht. Wenn der Zustand von node_modules nach dem Ausführen von npm i genau mit dem package-lock.json übereinstimmt und der Zustand von node_modules nach dem Ausführen von npm ci genau gleich ist Endergebnis - in fast allen Szenarien, vorausgesetzt, der Computer, auf dem Sie bauen, hat bereits einige/die meisten Abhängigkeiten im Ordner, wäre npm i nicht schneller? Es wird nur nicht heruntergeladen, was bereits lokal vorhanden ist und der erforderlichen Version entspricht.

Warum sollte ich lieber alles von Grund auf löschen und herunterladen?

Nein, npm ci ist immer noch schneller, da es den Deptree nicht erneut überprüft, einige Konsolenausgaben werden nicht durchgeführt.

Warum sollte ich lieber alles von Grund auf löschen und herunterladen?

Um Probleme zu vermeiden, ist ci für bestimmte Umgebungen wie Bereitstellungen gedacht.
Ich denke, die Dokumente erwähnen bereits die Unterschiede.

Es kann erheblich schneller sein als eine normale npm-Installation, indem bestimmte benutzerorientierte Funktionen übersprungen werden. Es ist auch strenger als eine normale Installation, was dazu beitragen kann, Fehler oder Inkonsistenzen zu erkennen, die durch die inkrementell installierten lokalen Umgebungen der meisten npm-Benutzer verursacht werden.

Siehe auch https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

npm ci ist noch schneller.

Wenn Sie also npm i , ist die Zeit, die benötigt wird, um das aktuelle node_modules zu lesen und herauszufinden, welche Pakete heruntergeladen werden sollten, erheblich länger als die Zeit, die es dauert, alle Pakete von npm herunterzuladen Server? Ich würde gerne ein tatsächliches Experiment sehen, das es misst.

Und ich verstehe diesen Absatz auch nicht -

npm ci bypasses a package’s package.json to install modules from a package’s lockfile. This ensures reproducible builds—you are getting exactly what you expect on every install.

Haben wir hier nicht gerade festgestellt, dass beim Ausführen von npm i die genauen Versionen in der Datei package-lock.json verwendet werden und der Zustand von node_modules nach dem Ausführen identisch mit dem Zustand ist, den es würde? nachdem Sie npm ci ? Die Builds werden also genauso reproduzierbar sein.

AKTUALISIEREN:

Ich habe folgenden Test gemacht -
Ich habe ein neues create-react-app Projekt erstellt. Nachdem es seine Initialisierung abgeschlossen hatte, hatte es ein package.json mit 7 direkten Abhängigkeiten und ein package-lock.json , das 1982 Pakete enthielt.
In diesem Zustand ( node_modules enthält alle Abhängigkeiten) dauert das Ausführen von npm i

real    0m2.548s
user    0m2.659s
sys     0m0.182s

Als ich einen einzelnen Paketordner ( node_modules/babel-eslint ) löschte und dann npm i erneut ausführte, dauerte es

real    0m3.295s
user    0m3.543s
sys     0m0.434s

um die fehlende Abhängigkeit erneut herunterzuladen

Als ich den gesamten node_moduels Ordner löschte und npm i erneut ausführte, dauerte es

real    0m16.701s
user    0m19.251s
sys     0m10.379s

Als ich npm ci , dauerte es

real    0m20.997s
user    0m23.844s
sys     0m14.857s

Dies war nicht viel anders, als ich versuchte, ein einzelnes Paket zu entfernen oder sogar den gesamten node_modules Ordner vor dem Anruf manuell zu löschen. Es war nicht überraschend, da npm ci node_modules sowieso damit beginnt, den Inhalt von

Nach jedem Durchlauf habe ich diff -q -r node_modules_orig/ node_modules/ , um sicherzustellen, dass das Ergebnis mit den ursprünglichen Abhängigkeiten identisch ist. Es war immer.

Zusammenfassend lässt sich sagen, dass die Verwendung von npm ci auf meinem Computer ~21 Sekunden dauert, unabhängig vom aktuellen Status von node_modules . Die Verwendung von npm i in einem kürzlich geklonten Projekt (kein node_modules ) dauert ~18 Sekunden und die Ausführung in einem Projekt ohne geänderte Abhängigkeiten (das aktuelle node_modules entspricht den erforderlichen Abhängigkeiten .) ) dauert ~3 Sekunden.

Wann wäre also die Verwendung von npm ci vorzuziehen? Es scheint nicht schneller zu sein (obwohl dies natürlich nur ein einzelner Test ist) und das Endergebnis ist identisch mit npm i , daher wäre der nachfolgende Build genauso zuverlässig.

npm ci ist vorzuziehen, wenn Sie _genau_ das brauchen, was in package-lock.json und nichts anderes. npm i garantiert nicht, dass genau das installiert wird, was in package-lock.json . Dies ist beabsichtigt. package-lock.json ist zwar eine Eingabe für npm i , aber auch eine Ausgabe.

Ich glaube, es gibt nur noch wenige Fälle, in denen npm i etwas anderes installieren würde (und somit package-lock.json modifizieren würde), wie vielleicht Paketversionen, die vorläufig gelöscht wurden.

Als npm ci zum ersten Mal eingeführt wurde, ignorierte npm i entweder package-lock.json direkt oder war zumindest viel proaktiver bei der Installation verschiedener Versionen.

So oder so ist es nicht wirklich wichtig. npm ci ist nur in Ordnung, wenn der Ordner node_modules noch nicht existiert. Ansonsten ist es unerschwinglich langsam, insbesondere unter Windows. Also braucht npm i einfach ein Flag, das _garantiert_, dass es package-lock.json nicht modifiziert und genau das installiert, was in package-lock.json .

Ich sehe keinen Sinn darin, weiter über das Warum und Wie zu diskutieren. Entweder wir kriegen es hin oder nicht. So wie es ist, npm ci scheiße.

/aktualisieren:
Hier ist ein Repo, in dem das Ausführen von npm i package-lock.json ändert: https://github.com/fuzzykiller/npm-install-demo

Obwohl die Änderungen nur technischer Natur sind, sind sie dennoch nicht akzeptabel.

Nur um es kurz zu wiederholen:

• npm ci löscht immer den Inhalt von node_modules absichtlich, was für Nicht-Produktions-Builds unerwünscht ist, weil es langsam ist. Es verwendet jedoch exakte Versionen von Paketen in package-lock.json , was für mehrere Situationen wünschenswert ist.

• npm install aktualisiert nur den Inhalt von node_modules , was sehr performant ist, aber vom Design her ignoriert es den Inhalt von package-lock.json wenn sich die package.json Versionsnummern unterscheiden für mehrere Situationen unerwünscht.

• npm install --package-lock-only wird in den Dokumenten beschrieben :

  Das Argument --package-lock-only aktualisiert nur package-lock.json, anstatt node_modules zu überprüfen und Abhängigkeiten herunterzuladen.

  Dies scheint für keines der oben beschriebenen Szenarien sinnvoll zu sein.

Was die Leute in den letzten 3 Jahren gefragt haben:

1. Ein Befehl (überall), der package.json ignoriert und _nur_ package-lock.json als die endgültige Quelle der zu installierenden Pakete respektiert.

2. Dadurch wird nicht der gesamte Inhalt von node_modules gelöscht und alles von Grund auf neu heruntergeladen.

Soweit ich sowohl aus den Dokumenten als auch aus den lokalen Tests entnehmen kann, erfüllt npm install Punkt 2, aber nicht 1. npm ci erfüllt Punkt 1, aber nicht 2. npm install --package-lock-only erfüllt keine dieser Anforderungen.

Ich bin mir nicht ganz sicher, warum dieses Problem geschlossen wurde, es gibt immer noch keine Möglichkeit, das gewünschte Verhalten zu erzielen.

Bearbeiten: Um das Beispiel von @fuzzykiller zu erweitern, wird nicht nur package-lock.json aktualisiert. Das wäre ärgerlich, aber es würde keinen meiner Builds zerstören. Aber wenn package.json irgendwo unscharfe Abhängigkeiten aufgelistet hat und eine Bugfix-Version dieser Abhängigkeiten veröffentlicht wird, werden sie geändert, wenn ich npm install auf einer neuen Maschine ausführe. Plötzlich habe ich Installationsunterschiede zwischen zwei Maschinen. Wir sind in meiner Firma auf Fehler durch genau dieses Verhalten gestoßen, es ist nicht nur so, dass package-lock.json erneut in Git eingecheckt werden muss.

In dieser Situation ist es wünschenswert, einen Befehl zu haben, der sich wie npm ci verhält – der eine reproduzierbare Installation basierend _nur_ auf dem Inhalt von package-lock.json . Das Löschen des Inhalts des Ordners node_modules verlangsamt Builds jedoch für einige Umgebungen und Situationen zu sehr, obwohl dies für einen endgültigen Produktionsbuild ein angemessenes Verhalten ist.

Es könnte überall eine Flagge geben, um dieses Problem zu beheben. Es könnte npm install --from-lockfile . Es könnte npm ci --preserve-existing . Aber im Moment scheint es, als wären wir in einem Kreis, in dem jeder, der um eine Flagge bittet, um zu npm install hinzugefügt zu werden, auf npm ci als Lösung hingewiesen wird, und jeder, der nach einer Flagge fragt npm ci wird auf npm install als Lösung verwiesen. Dieses Problem wurde geschlossen und zeigte auf npm install --package-lock-only , aber dieses Flag ist fast das Gegenteil von dem, was die Leute verlangen. Es respektiert package-lock.json als maßgebliche Quelle und aktualisiert oder installiert auch keine der Abhängigkeiten im Ordner node_modules :)

Dieses Thema sollte erneut geöffnet werden.