npm 5 a été publié aujourd'hui et l'une des nouvelles fonctionnalités comprend les installations déterministes avec la création d'un fichier _package-lock.json
_.
Ce fichier est-il censé être conservé dans le contrôle de source?
Je suppose que cela ressemble à yarn.lock
et composer.lock
, les deux étant supposés être conservés dans le contrôle de source.
Oui, _package-lock.json
_ est destiné à être vérifié dans le contrôle de source. Si vous utilisez npm 5, ceci peut apparaître sur la ligne de commande: _created a lockfile as package-lock.json. You should commit this file.
_ Selon npm help package-lock.json
:
_
package-lock.json
_ est automatiquement généré pour toutes les opérations où npm modifie l’arborescence _node_modules
_ ou _package.json
_. Il décrit l'arborescence exacte générée, de sorte que les installations ultérieures puissent générer des arborescences identiques, quelles que soient les mises à jour de dépendance intermédiaires.Ce fichier est destiné à être validé dans les référentiels sources et sert à plusieurs fins:
Décrivez une représentation unique d'un arbre de dépendance de sorte que les coéquipiers, les déploiements et l'intégration continue soient garantis pour installer exactement les mêmes dépendances.
Fournissez aux utilisateurs une possibilité de "voyager dans le temps" vers les états précédents de _
node_modules
_ sans avoir à valider le répertoire lui-même.Pour permettre une meilleure visibilité des modifications d'arborescence via des diffs de contrôle de source lisibles.
Optimisez également le processus d’installation en permettant à npm d’ignorer les résolutions de métadonnées répétées pour les packages précédemment installés.
Un détail important sur _
package-lock.json
_ est qu'il ne peut pas être publié et qu'il sera ignoré s'il se trouve ailleurs que dans le package de niveau supérieur. Il partage un format avec npm-shrinkwrap.json (5), qui est essentiellement le même fichier, mais permet la publication. Cela n'est pas recommandé à moins de déployer un outil CLI ou d'utiliser autrement le processus de publication pour produire des packages de production.Si _
package-lock.json
_ et _npm-shrinkwrap.json
_ sont tous deux présents dans la racine d'un paquet, _package-lock.json
_ sera complètement ignoré.
Oui, il est destiné à être archivé. Je tiens à suggérer qu’il obtient son propre commit unique. Nous constatons que cela ajoute beaucoup de bruit à nos diffs.
Oui, la meilleure pratique est de procéder à l'enregistrement (OUI, ENREGISTREMENT)
Je suis d'accord que cela va causer beaucoup de bruit ou de conflit en voyant le diff. Mais les avantages sont:
^1.2.3
dans votre package.json
, mais comment pouvez-vous vous assurer à chaque fois que npm install
récupérera la même version dans votre machine de développement et sur le serveur de construction, en particulier ces packages de dépendance indirecte? Eh bien, package-lock.json
vous le garantira. (Avec l'aide de npm ci
qui installe les paquets basés sur le fichier de verrouillage)npm audit fix
(je pense que la fonctionnalité d'audit provient de npm version 6).Je n'engage pas ce fichier dans mes projets. À quoi ça sert ?
Bien que c’est vrai que je n’utilise jamais ^ dans mon package.json pour les bibliothèques car j’ai eu de mauvaises expériences avec lui :)
Cordialement.
Aux personnes se plaignant du bruit causé par git diff:
git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'
Ce que j'ai fait était d'utiliser un alias:
alias Gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"
Pour ignorer package-lock.json dans les diffs de l'ensemble du référentiel (tous ceux qui l'utilisent), vous pouvez ajouter ceci à .gitattributes
:
package-lock.json binary
yarn.lock binary
Cela entraînera des différences indiquant "Les fichiers binaires a/package-lock.json et b/package-lock.json diffèrent chaque fois que le fichier de verrouillage du paquet est modifié. De plus, certains services Git (notamment GitLab, mais pas GitHub) excluent également ces fichiers (pas plus de 10 000 lignes modifiées!) des diffs lors de la visualisation en ligne.
Oui, vous pouvez valider ce fichier. De la documentation officielle de npm :
package-lock.json
est généré automatiquement pour toutes les opérations oùnpm
modifie soit l'arborescencenode_modules
, soitpackage.json
. Il décrit l'arborescence exacte générée, de sorte que les installations ultérieures puissent générer des arborescences identiques, quelles que soient les mises à jour de dépendance intermédiaires.Ce fichier est destiné à être validé dans les référentiels sources [.]
Oui tu devrais:
package-lock.json
. npm ci
au lieu de npm install
lors de la construction de vos applications à la fois sur votre CI et sur votre ordinateur de développement local.Le flux de travaux npm ci
requiert l'existence d'un package-lock.json
.
Un gros inconvénient de la commande npm install
est son comportement inattendu, qui risque de transformer le package-lock.json
, alors que npm ci
utilise uniquement les versions spécifiées dans le fichier de verrouillage et génère une erreur si le package-lock.json
et package.json
sont désynchronisés ou si un package-lock.json
était manquant.
Par conséquent, exécuter npm install
localement, en particulier. dans les grandes équipes composées de plusieurs développeurs, il peut en résulter de nombreux conflits au sein de package-lock.json
et les développeurs doivent alors décider de supprimer complètement le package-lock.json
.
Pourtant, il existe un cas d'utilisation convaincant permettant de croire que les dépendances du projet sont résolues de manière répétée de manière fiable sur différentes machines.
D'un package-lock.json
vous obtenez exactement cela: un état connu pour fonctionner.
Auparavant, j’avais des projets sans les fichiers package-lock.json
/npm-shrinkwrap.json
/yarn.lock
dont la construction échouerait un jour car une dépendance aléatoire obtenait une mise à jour complète.
Ces problèmes sont difficiles à résoudre car vous devez parfois deviner quelle était la dernière version de travail.
Si vous souhaitez ajouter une nouvelle dépendance, vous exécutez toujours npm install {dependency}
. Si vous souhaitez mettre à niveau, utilisez npm update {dependency}
ou npm install ${dependendency}@{version}
et validez le package-lock.json
modifié.
Si une mise à niveau échoue, vous pouvez revenir au dernier package-lock.json
de travail connu.
Pour quote npm doc :
Il est fortement recommandé de valider le verrou de paquet généré dans le contrôle de source: cela permettra à tous les membres de votre équipe, à vos déploiements, à votre intégration CI/continue et à tous ceux qui exécutent l'installation de npm dans votre source de paquet d'obtenir le même arbre de dépendance. que vous développiez. En outre, les différences de ces modifications sont lisibles par l'homme et vous informeront de toutes les modifications apportées par npm à votre node_modules. Vous pourrez ainsi savoir si des dépendances transitives ont été mises à jour, levées, etc.
Et en ce qui concerne le différence entre npm ci
vs npm install
:
- Le projet doit avoir un package-lock.json ou un npm-shrinkwrap.json existant.
- Si les dépendances du verrou de package ne correspondent pas à celles de package.json,
npm ci
se ferme avec une erreur au lieu de mettre à jour le verrou de package.npm ci
ne peut installer que des projets entiers à la fois: des dépendances individuelles ne peuvent pas être ajoutées avec cette commande.- Si un
node_modules
est déjà présent, il sera automatiquement supprimé avant quenpm ci
ne commence son installation.- Il n'écrira jamais dans
package.json
ni dans aucun des paquets-verrouillés: les installations sont essentiellement gelées.
Remarque: j'ai posté une réponse similaire ici
Désactivez package-lock.json globalement
tapez ce qui suit dans votre terminal:
npm config set package-lock false
cela fonctionne vraiment pour moi comme par magie
Oui, il est courant de commettre package-lock.json.
La raison principale de la validation de package-lock.json est que tout le monde dans le projet utilise la même version de package.
Avantages:-
Tout le monde dans le projet sera sur la même version du package, tout ce que vous avez à faire est
npm installer
Si vous suivez un contrôle de version strict et n'autorisez pas la mise à jour automatique des versions majeures pour vous préserver des modifications incompatibles avec les versions antérieures des packages tiers, le verrouillage du package aide beaucoup.
Les inconvénients:-
Mon utilisation de npm est de générer des fichiers css/js minified/uglified et de générer le javascript nécessaire dans les pages servies par une application Django. Dans mes applications, JavaScript s'exécute sur la page pour créer des animations, parfois effectuer des appels ajax, travailler dans un cadre VUE et/ou avec le fichier css. Si package-lock.json a un contrôle prioritaire sur ce qu'il y a dans package.json, il peut être nécessaire qu'il existe une version de ce fichier. Selon mon expérience, cela n’affecte pas ce qui est installé lors de l’installation de npm, ou s’il le fait, cela n’a pas, à ma connaissance, nui aux applications que je déploie. Je n'utilise pas mongodb ou d'autres applications de ce type qui sont traditionnellement des clients légers.
Je supprime package-lock.json du référentiel car npm install génère ce fichier, et npm install fait partie du processus de déploiement sur chaque serveur qui exécute l'application. Le contrôle de version de node et npm se fait manuellement sur chaque serveur, mais je veille à ce qu’ils soient identiques.
Lorsque npm install
est exécuté sur le serveur, il modifie package-lock.json. S'il modifie un fichier enregistré par le référentiel sur le serveur, le prochain déploiement WONT vous permettra d'extraire les nouvelles modifications depuis Origin. . En d'autres termes, vous ne pouvez pas déployer car l'extraction écrasera les modifications apportées à package-lock.json.
Vous ne pouvez même pas écraser un package-lock.json généré localement avec ce qui se trouve sur le référentiel (réinitialiser le maître d'origine), car npm se plaindra chaque fois que vous exécuterez une commande si le package-lock.json ne reflète pas le contenu de celui-ci. node_modules en raison de l'installation de npm, interrompant ainsi le déploiement. Maintenant, si cela indique que des versions légèrement différentes ont été installées dans node_modules, encore une fois, cela ne m'a jamais causé de problèmes.
Si node_modules ne figure pas dans votre référentiel (et il ne devrait pas l'être), package-lock.json doit être ignoré.
S'il me manque quelque chose, corrigez-moi dans les commentaires, mais le fait que le contrôle de version soit pris dans ce fichier n'a aucun sens. Le fichier package.json contient des numéros de version, et je suppose que ce fichier est celui utilisé pour créer les packages lors de l'installation de npm. Lorsque je le supprime, npm install se plaint comme suit:
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'
et la construction échoue. Cependant, lors de l’installation de node_modules ou de l’application de npm à js/css, aucune réclamation n’est formulée si je supprime package-lock.json.
jason@localhost:introcart_wagtail$ rm package-lock.json
jason@localhost: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 ...