web-dev-qa-db-fra.com

Est-ce que je valide le fichier package-lock.json créé par npm 5?

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.

node.jsgitnpmversion-controllockfile
1074
rink.attendant.6

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é.

1292
vine77

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.

95
xer0x

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. garantit exactement la même version de chaque paquet. Cette partie est la plus importante lors de la construction dans différents environnements et à différentes époques. Vous pouvez utiliser ^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)
  2. cela améliore le processus d'installation.
  3. cela aide avec la nouvelle fonctionnalité d'audit npm audit fix (je pense que la fonctionnalité d'audit provient de npm version 6).
46
Xin

Je n'engage pas ce fichier dans mes projets. À quoi ça sert ?

  1. C'est généré
  2. C'est la cause d'une erreur d'intégrité du code SHA1 dans gitlab avec les builds gitlab-ci.yml

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.

30
Deunz

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.

26
Raza

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'arborescence node_modules, soit 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 [.]

15
Bablu Singh

Oui tu devrais:

  1. valide le package-lock.json.
  2. utilisez 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 que npm 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

10
k0pernikus

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

3
Balogun Ridwan Ridbay

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:-

  • Cela peut donner à vos demandes de pull une apparence moche :) '
2
Nikhil Mohadikar

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 ...
1
MagicLAMP