Question 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 comprennent des installations déterministes avec la création d'un package-lock.json fichier.

Ce fichier est-il censé être conservé dans le contrôle de la source?

Je suppose que c'est semblable à yarn.lock et composer.lock, les deux étant censés être conservés dans le contrôle de la source.


567
2018-05-26 17:03


origine


Réponses:


Oui, package-lock.json est destiné à être vérifié dans le contrôle de la source. Si vous utilisez npm 5, vous pouvez le voir 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 généré automatiquement pour toutes les opérations où npm   modifie soit le node_modules arbre, ou package.json. Il décrit le   arbre exact qui a été généré, de sorte que les installations ultérieures sont en mesure de   générer des arborescences identiques, indépendamment des mises à jour de dépendance intermédiaires.

Ce fichier est destiné à être validé dans des référentiels sourceset sert   divers buts:

  • Décrire une seule représentation d'une arborescence de dépendances de sorte que les membres de l'équipe, les déploiements et l'intégration continue soient assurés d'installer exactement les mêmes dépendances.

  • Fournir une installation permettant aux utilisateurs de «voyager dans le temps» jusqu'aux états de node_modules sans avoir à valider le répertoire lui-même.

  • Pour faciliter la visibilité des changements d'arborescence grâce à des différences de contrôle de source lisibles.

  • Et optimisez le processus d'installation en permettant à npm d'ignorer les résolutions de métadonnées répétées pour les paquets précédemment installés.

Un détail clé à propos de package-lock.json est qu'il ne peut pas être publié, et il   sera ignoré s'il se trouve dans un endroit autre que le paquet toplevel. Il partage   un format avec npm-shrinkwrap.json (5), qui est essentiellement le même fichier, mais   permet la publication. Ceci n'est pas recommandé sauf si vous déployez un outil CLI ou   sinon, utiliser le processus de publication pour produire des paquets de production.

Si les deux package-lock.json et npm-shrinkwrap.json sont présents dans la racine de   un paquet, package-lock.json sera complètement ignoré.


684
2018-05-26 22:16



Oui, il est destiné à être archivé. Je veux suggérer qu'il obtient son propre engagement unique. Nous constatons qu'il ajoute beaucoup de bruit à nos diffs.


59
2018-06-16 21:18



Vous pouvez vérifier les documents officiels: https://docs.npmjs.com/files/package-lock.json

Oui, vous pouvez valider ce fichier. package-lock.json est généré automatiquement pour toutes les opérations où npm modifie soit le node_modules arbre, ou package.json. Il décrit l'arborescence exacte qui a été générée, de sorte que les installations ultérieures peuvent générer des arborescences identiques, indépendamment des mises à jour de dépendances intermédiaires.


10
2017-10-06 07:34



Oui, la meilleure pratique consiste à vérifier

Je suis d'accord que cela causera beaucoup de bruit ou de conflit en voyant le diff. Mais les avantages sont:

  1. garantir exactement la même version de chaque paquet. C'est le plus important lors de la construction dans des environnements différents à un moment différent. Vous pouvez utiliser ^1.2.3 dans ton package.json, mais comment pouvez-vous vous assurer à chaque fois npm install va ramasser la même version dans votre machine dev et dans le serveur de construction? Spécial ces paquets de dépendance indirects. Bien, package-lock.jsonveillera à ce que.
  2. cela améliore le processus d'installation
  3. il aide avec la nouvelle fonctionnalité d'audit npm audit fix (Je pense que la fonctionnalité d'audit est de la version 6 de npm)

6
2018-06-15 03:23



Je ne commets pas ce fichier dans mes projets. À quoi ça sert ?

  1. C'est généré
  2. C'est la cause d'une erreur de code SHA1 err dans gitlab avec les constructions gitlab-ci.yml

Bien que ce soit vrai que je n'utilise jamais ^ dans mon package.json pour les libs car j'ai eu de mauvaises expériences :)

Cordialement.


4
2017-07-12 14:53



Pour les gens qui se plaignent du bruit en faisant git diff:

git diff -- . ':(exclude)*package-lock.json'

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'"

2
2018-06-22 07:04



Note: Tout d'abord, je n'ai pas été en mesure de faire le ci-dessous suggéré   travail de solution, mais je pense que, avec plus de connaissances sur le sujet, nous pouvons   fais-le fonctionner. Faites-moi savoir si cela vous a aidé ou si j'ai compris   sur npm-merge-driver est faux.

Comme dit par beaucoup ici it will cause a lot of noise or conflict, dans ce cas, exécutez:

npx npm-merge-driver install -g

Et

npx npm-merge-driver install
$ git merge my-conflicting-branch
npm WARN conflict A git conflict was detected in package-lock.json. Attempting to auto-resolve.

added 1 package in 0.077s
Auto-merging package-lock.json
Merge made by the 'recursive' strategy.
 package-lock.json | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
$ git status
<clean>

Vérifiez plus sur docs ici: https://www.npmjs.com/package/npm-merge-driver


-1
2018-06-21 06:43