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

Question

mnp 5 a été libéré aujourd'hui et l'une des nouvelles fonctionnalités incluent déterministe s'installe avec la création d'un package-lock.json le fichier.

Est ce fichier censé rester dans le contrôle de code source?

Je suis en supposant qu'elle est similaire à l' yarn.lock et composer.lock, qui sont censés être conservés dans le contrôle de source.

Answer 1

Oui, package-lock.json est destiné à vérifier dans le contrôle de source. Si vous utilisez des mnp 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ù la ngp modifie soit le node_modules arbre, ou package.json. Il décrit l' exacte de l'arbre qui les a produits, tels que par la suite, installe sont en mesure de générer des arbres identiques, quel que soit intermédiaire de la dépendance des mises à jour.

Ce fichier est destiné à être engagé dans la source de référentiels, et sert diverses fins:

• Décrire une seule représentation d'un arbre de dépendances telles que les coéquipiers, les déploiements, et d'intégration continue sont garantis à installer exactement les mêmes dépendances.

• Fournir des installations pour les utilisateurs de "voyage dans le temps" à des états antérieurs de l' node_modules sans avoir à commettre le répertoire lui-même.

• Afin de faciliter une plus grande visibilité des modifications apportées à l'arbre à travers lisible de la source de contrôle de diff.

• Et d'optimiser le processus d'installation en permettant mnp à sauter répété des métadonnées pour des résolutions précédemment installé les packages.

L'une des clés de détails sur package-lock.json , c'est qu'il ne peut pas être publié, et il sera ignoré si trouvé, dans tout autre lieu que le toplevel paquet. Il partage un format avec npm-emballé.json(5), qui est essentiellement le même fichier, mais permet la publication. Ce n'est pas recommandé, à moins que le déploiement d'un outil CLI ou sinon, en utilisant le processus de publication pour la production de blocs 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é.

Answer 2

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.

Answer 3

Oui, la meilleure pratique consiste à vérifier le

Je suis d'accord qu'il va causer beaucoup de bruit ou de conflit au moment de voir la diff. Mais les avantages sont les suivants:

1. garantie même version exacte de chaque paquet. Cette partie est la plus importante lors de la construction dans des environnements différents à des moments différents. Vous pouvez utiliser ^1.2.3 votre package.json, mais comment peut-u s'assurer à chaque fois npm install va prendre la même version dans votre dev machine et le serveur de build, en particulier ceux dépendance indirecte paquets? Eh bien, package-lock.json veillera à ce que. (Avec l'aide d' npm ci qui installe les paquets en fonction de verrouillage de fichier)
2. il améliore le processus d'installation.
3. elle contribue à la nouvelle fonctionnalité d'audit npm audit fix (je pense que la fonctionnalité d'audit est de mnp version 6).

Answer 4

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.

Answer 5

Les gens se plaignent du bruit lorsque vous faites git diff:

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

Ce que j'ai fait a été 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 paquet-lock.json dans diff pour l'ensemble du référentiel (tout le monde l'utilise), vous pouvez ajouter ceci à .gitattributes:

package-lock.json binary
yarn.lock binary

Il en résultera des diffs qui montrent "des fichiers Binaires a/paquet-lock.json et b/paquet-lock.json diffèrent à chaque fois que le paquet de verrouiller le fichier a été modifié. En outre, certains Git services (notamment GitLab, mais pas GitHub) sera également exclure ces fichiers (pas plus de 10k lignes de changé!) à partir de la diff lors de la visualisation en ligne quand vous le faites.