Ce n'est pas ce que ci / cleaninstall est censé faire. Le comportement actuel est correct. Ce que vous voulez utiliser est npm shrinkwrap .

Nous avons ajouté une mise à jour pour éviter de supprimer le _dossier_ node_modules mais pas son _contenu_ (comme demandé à l'origine sur ce post). Le but de la commande npm ci est de tout supprimer pour repartir de zéro. Si vous souhaitez conserver vos anciens node_modules, vous avez besoin de npm i .

Merci pour vos réponses ! Désolé pour ma réponse tardive. J'ai regardé npm shrinkwrap mais est-ce destiné à s'exécuter sur notre serveur de build pour une intégration continue ? Lors de l'exécution de cette commande, elle renomme mon package-lock.json en npm-shrinkwrap.json mais que dois-je ensuite exécuter pendant CI ? Juste npm install pour avoir une mise à jour incrémentielle ? Ou devrais-je exécuter npm ci mais cela supprimera à nouveau tous les packages :-( Ce que je recherche, c'est une commande qui effectue une mise à jour incrémentielle mais installera exactement ce qui se trouve dans notre package-lock.json

@claudiahdz; D'après ce que je comprends, l'exécution de npm install pendant CI mettra à jour le package-lock.json et cela pourrait signifier que l'exécution de la même version quelques semaines plus tard installerait différents packages. Est-ce incorrect ?

Ps, je pensais que npm ci était l'abréviation de Continuous Integration

Comme référencé ici : https://github.com/npm/npm/issues/20104#issuecomment-403321557

Le comportement actuel est problématique si vous utilisez npm ci intérieur d'un conteneur Docker (ce qui est assez courant pour l'intégration continue) et que vous avez un montage lié sur node_modules

Cela provoque l'erreur suivante :

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'

ce qui entraîne alors l'abandon du conteneur Docker.

Ce serait bien d'avoir un indicateur --no-delete ou si npm ci pouvait supprimer le _contenu_ de node_modules mais pas le répertoire lui-même.

ci = installation propre

C'est prévu. Pourquoi n'utilisez-vous pas le npm i normal avec un fichier de verrouillage ?

Ce serait bien d'avoir un indicateur --no-delete ou si npm ci pouvait supprimer le contenu de node_modules mais pas le répertoire lui-même.

rm -rf node_modules/* && npm i

ci = installation propre

C'est prévu. Pourquoi n'utilisez-vous pas le npm i normal avec un fichier de verrouillage ?

...parce que : https://docs.npmjs.com/cli/ci.html

Cette commande est similaire à npm-install, sauf qu'elle est destinée à être utilisée dans des environnements automatisés tels que les plates-formes de test, l'intégration continue et le déploiement - ou dans toute situation où vous voulez vous assurer que vous effectuez une installation propre de vos dépendances. Cela peut être beaucoup plus rapide qu'une installation npm classique en ignorant certaines fonctionnalités orientées utilisateur. Il est également plus strict qu'une installation normale, ce qui peut aider à détecter les erreurs ou les incohérences causées par les environnements locaux installés de manière incrémentielle de la plupart des utilisateurs de npm.

Les installations plus rapides et l'approche de table rase en font un outil idéal pour les environnements CI tels que celui que j'ai mentionné ci-dessus.

rm -rf node_modules/* && npm i

C'est ce que je fais maintenant, mais voir ci-dessus pour le désir d'utiliser npm ci

Il me semble raisonnable de déposer une RFC demandant un indicateur de configuration qui fait que npm ci supprime le contenu de node_modules et non le répertoire lui-même. C'est également un problème pour moi, dans la mesure où j'ai configuré Dropbox pour ignorer sélectivement un répertoire node_modules , mais si je le supprime, ce paramètre sélectif disparaît, et la prochaine fois node_modules est créé, il se synchronise.

Il me semble raisonnable de déposer une RFC demandant un indicateur de configuration qui fait que npm ci supprime le _contenu_ de node_modules et non le répertoire lui-même. C'est également un problème pour moi, dans la mesure où j'ai configuré Dropbox pour ignorer sélectivement un répertoire node_modules , mais si je le supprime, ce paramètre sélectif disparaît, et la prochaine fois node_modules est créé, il se synchronise.

N'est-ce pas également ce que décrit un autre problème, permettre à npm de créer des fichiers pour ignorer le répertoire (pour OSX Spotlight et autres) ? Je pense qu'il y en avait aussi d'autres qui avaient besoin de cette fonctionnalité.

ci = installation propre

C'est prévu. Pourquoi n'utilisez-vous pas le npm i normal avec un fichier de verrouillage ?

npm i serait génial, mais seulement si cela ne changeait pas le fichier de verrouillage. J'ai vu le package-lock.json être mis à jour au cours d'un npm i ou cela ne devrait-il pas se produire ?

Je supporte cette fonctionnalité. Comme indiqué, npm i modifie package-lock.json. Un drapeau serait la solution idéale.

pareil, un drapeau serait super

Je supporte cette fonctionnalité. Comme indiqué, npm i modifie package-lock.json. Un drapeau serait la solution idéale.

Pourquoi ne pas ajouter un drapeau pour npm i alors ? Parce que cela n'aurait pas beaucoup de sens pour ci = clean install à mon sens.

Quelle partie de la "propre installation" est incompatible avec le maintien du répertoire parent node_modules/ (tout en effectuant une nouvelle installation du contenu réel) ?

Je me rends compte que CI ne signifie pas intégration continue dans ce cas ; mais une installation propre est souvent très utile dans un environnement d'intégration continue, comme la documentation l'indique clairement.

Cette commande est similaire à npm-install, sauf qu'elle est destinée à être utilisée dans des environnements automatisés tels que les plates-formes de test, l'intégration continue et le déploiement - ou dans toute situation où vous voulez vous assurer que vous effectuez une installation propre de vos dépendances. Cela peut être beaucoup plus rapide qu'une installation npm classique en ignorant certaines fonctionnalités orientées utilisateur. Il est également plus strict qu'une installation normale, ce qui peut aider à détecter les erreurs ou les incohérences causées par les environnements locaux installés de manière incrémentielle de la plupart des utilisateurs de npm.

npm ci est spécifiquement destiné à être utilisé dans des environnements automatisés, plusieurs fois cela signifie une configuration basée sur Docker.

Le comportement de suppression du répertoire node_module/ est gênant dans une configuration basée sur Docker, pour les raisons mentionnées dans ce fil.

Nous demandons donc une option qui rendra cette commande utile pour son objectif et son environnement.

Je supporte cette fonctionnalité. Comme indiqué, npm i modifie package-lock.json. Un drapeau serait la solution idéale.

Pourquoi ne pas ajouter un drapeau pour npm i alors ? Parce que cela n'aurait pas beaucoup de sens pour ci = clean install à mon sens.

Je dois poser cette question, y a-t-il d'autres différences entre npm install et npm ci sinon pourquoi les deux options ne sont-elles pas disponibles dans npm install peut-être ci besoins devenir un alias comme npm install --no-update-package-lock --clean-node-modules

Le comportement de suppression du répertoire node_module/ est gênant dans une configuration basée sur Docker, pour les raisons mentionnées dans ce fil.

À mon avis, cela ne devrait se produire qu'une seule fois lorsque l'image est construite. Après cela, npm i doit être utilisé pendant le développement.

peut-être que ci doit devenir un alias comme npm install --no-update-package-lock --clean-node-modules

Personnellement, cela a plus de sens pour moi, des indicateurs supplémentaires pour la commande normale npm i .

Je suis indifférent à ce que, et honnêtement trop d'un n00b avec js land pour avoir un argument concret qu'il doit être ci , tout ce que je sais, c'est qu'il ne devrait pas mettre à jour le package-lock.json et ne devrait pas supprimer node_modules

npm ci ne met pas à jour le fichier de verrouillage, il s'installe à partir du fichier de verrouillage. Cela a été introduit pour effectuer une installation propre car auparavant, il était conseillé aux personnes de rm -rf node_modules et de réexécuter npm i . Et de toute façon, les gens voulaient qu'il ne modifie pas le fichier de verrouillage mais qu'il s'installe à partir de celui-ci.

Alors npm ci est né. Et il saute également certaines choses comme la liste des packages installés et l'arborescence et quelques autres choses.

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

Il couvre un cas d'utilisation spécifique.

Pour d'autres cas d'utilisation, nous devrions ajouter de nouveaux drapeaux à npm i avec lesquels nous pouvons également émuler npm ci qui est une solution plus flexible et meilleure que les drapeaux pour npm ci qui ne devraient toujours couvrir que le cas d'utilisation actuel à mon humble avis. Ce que les utilisateurs demandent ici est un peu similaire à yarn install --frozen-lockfile ou yarn --frozen-lockfile .

Sinon les drapeaux sont répartis sur npm ci , npm i et ainsi de suite ce qui complique un peu la tâche (documentation, code, ...). C'est du moins ce que je pense. Mettons-le à npm i avoir des moyens plus puissants et flexibles pour configurer son comportement.

Pour les autres cas d'utilisation, nous devrions ajouter de nouveaux indicateurs à npm i avec lesquels nous pouvons également émuler npm ci qui est une solution plus flexible et meilleure que les indicateurs pour npm ci qui ne devraient toujours couvrir que le cas d'utilisation actuel à mon humble avis. Ce que les utilisateurs demandent ici est un peu similaire à wire install --frozen-lockfile ou wire --frozen-lockfile.

Je serais très heureux si la fonctionnalité était ajoutée à npm i . Dois-je mettre à jour le message d'origine ?

npm ci ne met pas à jour le fichier de verrouillage, il s'installe à partir du fichier de verrouillage. Cela a été introduit pour effectuer une installation propre car auparavant, il était conseillé aux personnes de rm -rf node_modules et de réexécuter npm i . Et de toute façon, les gens voulaient qu'il ne modifie pas le fichier de verrouillage mais qu'il s'installe à partir de celui-ci.

Alors npm ci est né. Et il saute également certaines choses comme la liste des packages installés et l'arborescence et quelques autres choses.

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

Il couvre un cas d'utilisation spécifique.

Pour d'autres cas d'utilisation, nous devrions ajouter de nouveaux drapeaux à npm i avec lesquels nous pouvons également émuler npm ci qui est une solution plus flexible et meilleure que les drapeaux pour npm ci qui ne devraient toujours couvrir que le cas d'utilisation actuel à mon humble avis. Ce que les utilisateurs demandent ici est un peu similaire à yarn install --frozen-lockfile ou yarn --frozen-lockfile .

Comment rm -rf node_modules/* n'est-il pas qualifié de "nettoyage" ? La fonctionnalité demandée ici est très similaire à celle présente dans npm ci. À mon avis, il est plus logique d'ajouter un indicateur à npm ci afin qu'il utilise rm -rf node_modules/* au lieu de rm -rf node_modules au lieu d'importer l'intégralité du comportement de npm ci dans npm i.

BTW, ce problème devrait attirer plus d'attention et les responsables devraient exprimer leurs opinions et leurs plans à ce sujet, l'utilisation de docker est fondamentalement toujours utilisée dans CI (intégration continue) qui est l'un des principaux cas d'utilisation de npm ci !

Veuillez ouvrir un RFC pour ce changement, plutôt qu'un problème dans ce référentiel.

Pour éviter toute confusion, je renommerais ce problème en "vide au lieu de supprimer le répertoire node_modules dans npm CI"

Mon intention de ce problème n'a jamais été de supprimer le dossier node_modules ou seulement son contenu. Il s'agissait toujours de préserver le contenu de node_modules mais assurez-vous qu'il est à jour et synchronisé avec package-lock.json . Donc une mise à jour incrémentielle qui adhère au package-lock.json .

Peut-être que je me trompe, mais je pense qu'il y a deux problèmes ici. Peut-être que quelqu'un pourrait lancer un autre problème ou RFC sur la suppression uniquement du contenu de node_modules au lieu de supprimer complètement le dossier ? Ou est-ce que j'ai raté quelque chose ?

@Zenuka, la raison pour laquelle npm CI est rapide et existe est qu'il ignore le répertoire node_modules existant, il est donc peu probable que cela change.

Dans notre cas d'utilisation, je pense qu'il serait plus rapide de vérifier si le dossier nodes_modules est à jour ou non. Et si ce n'est pas seulement mettre à jour les paquets qui devraient être mis à jour (comme npm i DOE) J'ai une machine virtuelle dédiée de course à pied comme agents de construction le fait d' exécuter une construction et de garder les nodes_modules dossier et tout le contenu est tout devrait être plus rapide que de tout supprimer et de le réinstaller. Nous exécutons notre build et testons les modifications de code bien plus que les modifications apportées à nos package.json ou package-lock.json .

Dans notre cas d'utilisation, je pense qu'il serait plus rapide de vérifier si le dossier nodes_modules est à jour ou non.

Eh bien, c'est (le calcul de l'arbre des packages) ce qui prend le plus de temps. Cette vérification ralentirait npm ci .

exécuter une compilation et conserver le dossier nodes_modules et tout son contenu devrait être plus rapide que de tout supprimer et de le réinstaller.

Probablement pas, c'est pourquoi npm ci été introduit, qui ignore ce que fait npm i (vérifiez l'arborescence des packages).

@Zenuka npm install est déjà le moyen le plus rapide possible de faire ce que vous voulez. npm ci n'a qu'un seul but : le faire plus rapidement, en supprimant node_modules afin qu'il n'ait pas à calculer de différence.

Probablement pas, c'est pourquoi npm ci a été introduit, qui ignore ce que npm i fait (vérifiez l'arborescence des packages).

J'ai testé cela uniquement sur ma machine (ce qui n'est bien sûr pas une bonne mesure), mais l'exécution de npm install sur un dossier node_modules termine en 10 secondes. Exécuter npm ci prend quelques minutes. Vous attendriez-vous à des résultats différents ?

Je suis fan de votre suggestion d'ajouter un indicateur pour geler le fichier de verrouillage avec npm install .

Vérifier que le contenu de package-lock.json est réellement présent est très rapide, même sous Windows. Voir https://github.com/fuzzykiller/verify-node-modules.

Vérifier que rien d'autre n'est présent dans node_modules prendrait certainement un peu plus de temps mais probablement encore moins d'une seconde.

Sur cette base, une version incrémentielle de npm ci pourrait facilement être créée. L'arbre est déjà calculé et enregistré dans package-lock.json , après tout.

De plus, fondamentalement, la seule raison npm ci laquelle package-lock.json . Sans se faufiler dans des améliorations surprises, comme le fait npm install .

juste mes 2 cents, j'ai personnellement basculé notre infra sur npm ci car j'en avais aussi marre du déploiement d'une ancienne balise npm i n'adhérerait pas au fichier de verrouillage... donc si c'est sérieusement ce gros problème pour ajouter le drapeau au niveau npm ci (ce que je reçois .. c'est clean install il fait ce qu'on lui dit) alors npm i REALLLLLYLYY a besoin de ce drapeau. mais je me souviens avoir fait des recherches à ce sujet et il y avait aussi un fil de discussion sur le npm i qui avait plus de 2 ans (et toujours ouvert) où l'équipe npm a suggéré aux gens d'utiliser npm ci lol ... ceci C'est un peu la raison pour laquelle les gens ont abandonné le npm dans le passé et sont simplement passés au fil.

encore une fois juste un autre point de vue des développeurs

J'ai mis mon vote pour ajouter la possibilité de garder les modules :heavy_plus_sign: .

+1 ici - comme l' ont dit @fuzzykiller , il n'y a pas de "sweet spot" entre npm install et npm ci qui GARDERA les node_modules, mais respectera toujours package-lock.json et fonctionnera plus vite.
Exécutez simplement aussi vite que possible - recherchez les dépendances de package-lock qui existent déjà dans node_modules, puis installez tout le reste manquant .. pas de mises à niveau, pas de suppression.

Personnellement, peu m'importe lequel ( install ou ci ) qui aurait ceci, mais tout cela ressemble à npm install devrait juste avoir des drapeaux pour tout et npm ci n'a pas besoin d'être une commande séparée.

C'est quelque peu frustrant, étant donné que npm ci été initialement présenté comme la solution au même problème que ce problème soulève.

Le comportement original qu'un certain nombre de personnes voulaient pour npm install était de regarder le package-lock.json au lieu de package.json . Nous voulions un indicateur sur npm install pour activer ce comportement. Ce que nous avons obtenu à la place était npm ci , parce que :

le package.json décrit les dépendances requises de votre projet. Si le fichier de verrouillage actuel ne peut pas les satisfaire, le fichier de verrouillage doit céder. Le but du fichier de verrouillage est de créer une installation reproductible sur différentes machines, et non de rendre obsolète le package.json.

Alors, bien. npm install n'est pas le bon endroit pour cette option, npm ci est. Sauf que npm ci ajoute des comportements supplémentaires (effacement du dossier node_modules ) qui l'empêchent d'être une solution utile au problème d'origine. Et la raison pour laquelle il ne peut pas y avoir d'indicateur sur npm ci maintenant est que :

ci = installation propre

C'est prévu. Pourquoi n'utilisez-vous pas le npm i normal avec un fichier de verrouillage ?

Ce qui... bien. Peu m'importe où le drapeau est ajouté. Je n'ai aucun intérêt dans la philosophie sous-jacente à l'interface. Mais le drapeau pourrait-il être ajouté quelque part ?

Zut, je ne soulèverais pas d'objections même si les gens voulaient une 3ème commande entièrement séparée, je m'en moque. La seule chose qui m'importe, c'est que 3 ans après le début de cette conversation sur le respect de package-lock.json pour les installations normales, il n'y a toujours aucun moyen d'obtenir le comportement que nous demandions à l'origine.

Sur mon lieu de travail, nous avons vu des bogues provenant de mises à jour de versions mineures et de corrections de bogues pour les packages. Nous voulons vraiment rechercher ces bogues uniquement lors des mises à niveau de packages ciblées, nous ne voulons pas que nos environnements de développement utilisent des versions de packages différentes de celles de nos environnements de production. La cohérence y est très importante. Quel que soit le nom que l'on veuille l'appeler ou l'endroit où l'on veut le mettre, nous voulons un moyen rapide d'obtenir des packages à partir du fichier de verrouillage qui ne nous obligera pas non plus à passer en revue les versions de node-gyp pour les modules déjà installés à chaque fois que nous exécutez la commande.

Voici comment j'aimerais que cela fonctionne dans un monde parfait :

• npm install - même comportement qu'aujourd'hui
• npm install --from-lockfile - installer à partir du fichier de verrouillage (comme le fait ci )
• npm install --clean - même comportement que npm install mais supprime le contenu node_modules
• npm ci - un alias de npm install --from-lockfile --clean

@jdussouillez C'est exactement ce qui devrait arriver. Très bien dit! J'aimerais voir cette solution mise en place.

Il est toujours frustrant de rencontrer ce problème où nous devons décider entre vitesse et cohérence pour un pipeline CI. Je l'ai rencontré 3 ou 4 fois pour différentes raisons au cours des 2 derniers mois seulement.

Cette fonctionnalité serait idéale pour Azure Pipelines et d'autres architectures cloud.

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

Étant donné que npm ci supprime le dossier node_modules pour garantir l'utilisation d'un ensemble de modules cohérent et reproductible, vous devez éviter de mettre en cache node_modules lors de l'appel de npm ci.

Fermeture : Comme @claudiahdz l'a mentionné, nous avons envoyé un correctif à ce comportement où npm ci ne supprime plus le dossier node_nodules lui-même mais uniquement son contenu (réf. https://github.com/npm /libcipm/blob/latest/CHANGELOG.md#407-2019-10-09). Cela a été expédié en [email protected] le 21 juillet (réf. https://github.com/npm/cli/blob/v6/CHANGELOG.md#6147-2020-07-21) et nous avons maintenu la même expérience dans npm@7 .

Si vous rencontrez un problème distinct avec npm ci ou toute autre commande, veuillez utiliser l'un de nos modèles de problème pour signaler un bogue : https://github.com/npm/cli/issues/new/choose

Notes de côté...

@jdussouillez apprécie les retours ; En termes d'installation directe à partir d'un fichier de verrouillage - vous pouvez le faire aujourd'hui avec le drapeau --package-lock-only (ex. npm install --package-lock-only ). En termes d'ajout d'un indicateur --clean à install , je n'ai pas l'impression que cela ajoute beaucoup de valeur, mais je peux me tromper. Si cela vous tient à cœur, nous aimerions que vous soumettiez un RFC sur https://github.com/npm/rfcs

Le commentaire fait par @claudiahdz il y a presque un an semble être lié au fait que le comportement de npm ci consiste à supprimer le contenu de node_modules , au lieu du dossier lui-même. Ce qui est pratique lors du montage dans un conteneur Docker (par exemple), mais ne change toujours pas le résultat final - npm ci téléchargera toutes les dépendances à partir de zéro.

L'utilisation de npm install --package-lock-only semble faire exactement le contraire du problème d'origine (si je comprends bien) - cela ne mettra à jour que le fichier package-lock.json et ne téléchargera aucune dépendance.

Ce que je comprends du problème d'origine, c'est la nécessité d'avoir une option qui obtient un état actuel du dossier node_modules , et un fichier package-lock.json , et télécharge uniquement les packages requis pour obtenir le node_modules versions pour correspondre au package-lock.json . Ce sera donc beaucoup plus rapide que de tout télécharger à chaque fois, avec le même résultat net à la fin.

N'est-ce pas ce que fait déjà npm install ?

N'est-ce pas ce que fait déjà npm install ?

AUTANT QUE JE SACHE -
npm install résoudra toutes les dépendances en fonction du fichier package.json (en ignorant le package-lock.json ), comparera avec ce qui se trouve actuellement dans le dossier node_modules , et téléchargera le dépendances qui doivent être téléchargées pour répondre aux exigences. Il mettra également à jour le package-lock.json conséquence.

Il n'ignore certainement pas le fichier de verrouillage - il prend juste en compte l'arborescence existante, ce que npm ci ne fait pas.

Vous avez raison, je suis désolé.
Je me souvenais mal (c'était peut-être le comportement du passé ?). Je viens de faire quelques tests avec un simple arbre de dep, et lorsque le fichier package-lock.json est présent, npm i installe exactement les versions qu'il spécifie, et ne change rien. C'était exactement le comportement que je recherchais, donc j'en suis content. ??
Je m'excuse d'avoir posté sur un sujet clos.

Ma demande initiale était en effet ce que décrit ATGardner :

Ce que je comprends du problème d'origine, c'est la nécessité d'avoir une option qui obtient un état actuel du dossier node_modules , et un fichier package-lock.json , et télécharge uniquement les packages requis pour obtenir le node_modules versions pour correspondre au package-lock.json . Ce sera donc beaucoup plus rapide que de tout télécharger à chaque fois, avec le même résultat net à la fin.

Mon expérience avec npm install est qu'il met parfois à jour le fichier package-lock.json . J'ai testé cela à nouveau ce matin avec un référentiel que je n'avais pas mis à jour depuis un moment et j'ai exécuté git pull et npm i . Cette fois, il n'a mis à jour aucune version, il a juste ajouté des dépendances et des packages supplémentaires.

Malheureusement, il s'agit d'un référentiel privé mais peut-être quelqu'un d'autre en tant que référentiel public reproductible ? Lorsqu'il y a plusieurs commits et que le basculement entre eux fait que npm install à jour le package-lock.json ?

Je me rends compte qu'il pourrait y avoir une erreur de l'utilisateur lorsqu'il ne commit pas le package-lock.json lors de la mise à jour du package.json mais mes collègues savent qu'ils devraient également mettre à jour le package-lock.json . Je vais me renseigner.

Je n'ai pas pu obtenir mon exemple simple pour que npm i modifie le fichier package-lock.json . Mais je vais l'essayer un peu plus.

Si npm i finit toujours par télécharger exactement les mêmes versions spécifiées dans le package-lock.json , tout en gardant autant que possible du node_modules actuel, pourquoi aurais-je besoin d'exécuter npm ci ? quel serait l'intérêt de tout supprimer avant de retélécharger ?

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

Je m'excuse encore de ne pas être le lieu de cette discussion. Y a-t-il un autre endroit plus préférable ?

Je ne comprends toujours pas. Si l'état de node_modules après l'exécution de npm i correspond exactement à package-lock.json , et l'état de node_modules après l'exécution de npm ci a exactement le même résultat final - dans presque tous les scénarios, en supposant que l'ordinateur sur lequel vous construisez a déjà certaines/la plupart des dépendances dans le dossier, npm i ne serait-il pas plus rapide ? Il ne téléchargera tout simplement pas ce qui est déjà présent localement et correspond à la version requise.

Pourquoi préférerais-je tout supprimer et tout télécharger à partir de zéro ?

Non, npm ci est toujours plus rapide car il ne vérifie pas à nouveau le deptree, certaines sorties de la console ne sont pas effectuées.

Pourquoi préférerais-je tout supprimer et tout télécharger à partir de zéro ?

Pour éviter les problèmes et ci est destiné aux environnements spécifiques tels que les déploiements.
Je pense que la doc mentionne déjà les différences.

Cela peut être beaucoup plus rapide qu'une installation npm classique en ignorant certaines fonctionnalités orientées utilisateur. Il est également plus strict qu'une installation normale, ce qui peut aider à détecter les erreurs ou les incohérences causées par les environnements locaux installés de manière incrémentielle de la plupart des utilisateurs de npm.

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

npm ci est encore plus rapide.

Ainsi, lorsque vous utilisez npm i , le temps nécessaire pour lire le node_modules actuel et déterminer quels packages doivent être téléchargés est nettement plus long que le temps nécessaire pour télécharger réellement tous les packages à partir de npm les serveurs? J'aimerais voir une expérience réelle qui le mesure.

Et je ne comprends pas non plus ce paragraphe -

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.

Ne venons-nous pas de conclure ici que l'exécution de npm i utilise les versions exactes du fichier package-lock.json , et que l'état de node_modules après l'exécution est identique à l'état qu'il aurait être après avoir exécuté npm ci ? Les builds seront donc tout aussi reproductibles.

METTRE À JOUR:

J'ai fait le test suivant -
J'ai créé un nouveau projet create-react-app . Une fois son initialisation terminée, il avait un package.json avec 7 dépendances directes et un package-lock.json qui contenait 1982 packages.
À cet état ( node_modules contient toutes les dépendances) - l'exécution de npm i prend

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

Lorsque j'ai supprimé un seul dossier de package ( node_modules/babel-eslint ), puis exécuté à nouveau npm i , il a fallu

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

pour retélécharger la dépendance manquante

Lorsque j'ai supprimé l'intégralité du dossier node_moduels et exécuté à nouveau npm i , il a fallu

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

Quand j'ai couru npm ci , il a fallu

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

Cela ne différait pas beaucoup lorsque j'ai essayé de supprimer un seul package, ou même de supprimer manuellement l'intégralité du dossier node_modules avant l'appel. Ce n'était pas surprenant, puisque npm ci commence par supprimer le contenu de node_modules toute façon.

Après chaque exécution, j'ai exécuté diff -q -r node_modules_orig/ node_modules/ pour m'assurer que le résultat est identique aux dépendances d'origine. Ça l'a toujours été.

Donc, pour conclure, il semble que l'utilisation de npm ci prenne environ 21 secondes sur ma machine, quel que soit l'état actuel de node_modules . Utiliser npm i sur un projet récemment cloné (pas de node_modules ) prend environ 18 secondes, et l'exécuter sur un projet qui n'a pas de dépendances modifiées (le node_modules actuel correspond aux dépendances requises ) prend environ 3 secondes.

Alors, quand utiliser npm ci serait-il préférable ? Cela ne semble pas plus rapide (bien sûr, il ne s'agit que d'un seul test), et le résultat final est identique à npm i , donc la construction suivante serait tout aussi fiable.

npm ci est préférable lorsque vous avez besoin _exactement_ de ce qu'il y a dans package-lock.json et rien d'autre. npm i ne garantit pas qu'il installera exactement ce qui est dans package-lock.json . C'est par conception. Alors que package-lock.json est une entrée de npm i , c'est aussi une sortie.

Je crois qu'il ne reste que quelques cas où npm i installerait quelque chose de différent (et donc modifierait package-lock.json ), comme peut-être des versions de package qui ont été supprimées.

À l'époque où npm ci été introduit pour la première fois, npm i ignorait carrément package-lock.json ou au moins était beaucoup plus proactif lors de l'installation de différentes versions.

De toute façon, cela n'a pas vraiment d'importance. npm ci n'est OK que lorsque le dossier node_modules n'existe pas encore. Sinon, sa lenteur est prohibitive, surtout sous Windows. Donc, npm i simplement besoin d'un indicateur qui _garantit_ qu'il ne modifiera pas package-lock.json et installera exactement ce qui se trouve à l'intérieur de package-lock.json .

Je ne vois aucun intérêt à discuter davantage du pourquoi et du comment. Soit on l'aura, soit on ne l'aura pas. Tel quel, npm ci craint.

/mettre à jour:
Voici un dépôt où l'exécution de npm i changera package-lock.json : https://github.com/fuzzykiller/npm-install-demo

Bien que les changements ne soient que de nature technique, ils ne sont toujours pas acceptables.

Juste pour réitérer rapidement :

• npm ci supprime toujours le contenu de node_modules par conception, ce qui n'est pas souhaitable pour les versions hors production car il est lent. Cependant, il utilise des versions exactes des packages trouvés dans package-lock.json , ce qui est souhaitable pour plusieurs situations.

• npm install met simplement à jour le contenu de node_modules , ce qui est très performant, mais par conception, il ignore le contenu de package-lock.json si les numéros de version package.json diffèrent, ce qui est indésirable pour plusieurs situations.

• npm install --package-lock-only est décrit dans la doc :

  L'argument --package-lock-only ne mettra à jour que package-lock.json, au lieu de vérifier les node_modules et de télécharger les dépendances.

  Cela ne semble utile pour aucun des scénarios décrits ci-dessus.

Ce que les gens demandent depuis 3 ans :

1. Une commande (n'importe où) qui ignorera package.json et respectera _only_ package-lock.json comme source définitive des packages qui seront installés.

2. Cela ne supprimera pas tout le contenu de node_modules et ne retéléchargera pas tout à partir de zéro.

D'après ce que je peux voir à la fois dans la documentation et dans les tests locaux, npm install satisfait le point 2, mais pas 1. npm ci satisfait le point 1, mais pas 2. npm install --package-lock-only n'en satisfait aucun de ces exigences.

Je ne sais pas exactement pourquoi ce problème a été fermé, il n'y a toujours aucun moyen d'obtenir le comportement souhaité.

Edit: Pour prolonger l'exemple de @fuzzykiller , ce n'est pas seulement que package-lock.json est mis à jour. Ce serait ennuyeux, mais cela ne briserait aucune de mes constructions. Mais si package.json a des dépendances floues répertoriées n'importe où et qu'une version de correction de bogues de ces dépendances est publiée, elles seront modifiées lorsque j'exécuterai npm install sur une nouvelle machine. Du coup, j'ai des différences d'installation entre deux machines. Nous avons rencontré des bugs dans mon entreprise à cause de ce comportement, ce n'est pas seulement que le package-lock.json doit être à nouveau archivé dans Git.

Il est souhaitable dans cette situation d'avoir une commande qui se comporte comme npm ci -- qui fait une installation reproductible basée _uniquement_ sur le contenu de package-lock.json . Cependant, la suppression du contenu du dossier node_modules ralentit trop les builds pour certains environnements et situations, même si c'est un comportement approprié pour une build de production finale.

Il pourrait y avoir un drapeau n'importe où pour résoudre ce problème. Cela pourrait être npm install --from-lockfile . Cela pourrait être npm ci --preserve-existing . Mais pour le moment, il semble que nous soyons dans un cercle où quiconque demande un drapeau à ajouter à npm install se voit désigner npm ci comme solution, et quiconque demande un drapeau sur npm ci est pointé sur npm install comme solution. Ce problème a été fermé en pointant vers npm install --package-lock-only , mais ce drapeau est presque le contraire de ce que les gens demandent. Il ne respecte pas package-lock.json comme source faisant autorité, et il ne met pas non plus à jour ou n'installe aucune des dépendances dans le dossier node_modules :)

Ce problème devrait être rouvert.