Devrais-je valider les fichiers yarn.lock et package-lock.json?
Nous utilisons du fil pour toutes nos installations pkg déterministes mais n'empêchons pas l'utilisateur d'utiliser npm - je suppose que le fait d'avoir ces deux fichiers causera toutefois des problèmes. Doit-on en ajouter dans votre répertoire .gitignore?
Toujours valider les fichiers de verrouillage de dépendance en général
Comme couvert ailleurs, les fichiers de verrouillage de dépendance, pris en charge par de nombreux systèmes de gestion de paquets (par exemple: composer et bundler ), doivent être validés. la base de code dans les projets de fin de chaîne - de sorte que chaque personne essayant de l'exécuter le fasse avec exactement l'ensemble de dépendances testé.
Il est moins clair de savoir si les fichiers de verrouillage doivent toujours être validés dans des packages destinés à être inclus dans d'autres projets (des dépendances plus souples sont souhaitables). Cependant, Yarn et NPM (comme couvert par @Cyrille) ignorent intelligemment yarn.lock et package-lock.json respectivement si nécessaire, ce qui permet de conserver en toute sécurité ces fichiers de verrouillage.
Donc, vous devriez toujours valider au moins un de yarn.lock ou package-lock.json en fonction du gestionnaire de paquets que vous utilisez.
Devez-vous commettre à la fois yarn.lock et package-lock.json?
Actuellement, nous avons deux systèmes de gestion de paquets différents, qui installent tous deux le même ensemble de dépendances à partir de package.json, mais génèrent et lisent à partir de deux fichiers de verrouillage différents. NPM 5 génère package-lock.json, alors que Yarn génère yarn.lock.
Si vous validez package-lock.json, vous créez un support pour les personnes installant vos dépendances avec NPM 5. Si vous validez yarn.lock, vous créez un support pour les personnes installant des dépendances avec Yarn.
Que vous choisissiez de valider yarn.lock ou package-lock.json, ou les deux, dépend du fait que ceux qui développent votre projet utilisent uniquement Yarn ou NPM 5, ou les deux. Si votre projet est open-source, la chose la plus conviviale pour la communauté serait probablement d'engager les deux et de mettre en place un processus automatisé pour vous assurer que yarn.lock et package-lock.json restent toujours synchronisés.
Mise à jour: Le fil a maintenant introduit ne commande import qui générera un fichier yarn.lock à partir d'un Fichier package-lock.json. Cela pourrait être utile pour garder les deux fichiers synchronisés. (Merci @weakish)
Cette question a été longuement discutée sur le projet Yarn à:
- "Idée: support package-lock.json à partir de npm 5"
- "Les fichiers de verrouillage concurrents créent une mauvaise UX"
Les deux sont maintenant fermés.
Vous devez valider 1 fichier de verrouillage de l’arbre de dépendance, mais vous ne devez pas valider les deux. Cela nécessite également la normalisation sur fil ou npm (pas les deux) pour construire + développer un projet avec.
Voici l'article de fil sur pourquoi yarn.lock doit être validé, si vous standardisez le fil.
Si vous validez le fichier yarn.lock ET les fichiers package-lock.json, les deux fichiers peuvent fournir de différentes manières différentes arborescences de dépendances (même si les algorithmes de résolution des arborescences narn et npm sont identiques). non-trivial pour s'assurer qu'ils fournissent exactement la même réponse. Étant donné que ce n'est pas trivial, il est peu probable que le même arbre de dépendance soit conservé dans les deux fichiers, et vous ne voulez pas de comportement différent selon que la génération a été réalisée à l'aide de yarn ou de npm.
Si et quand fil cesse d'utiliser yarn.lock en package-lock.json ( numéro ici ), le choix du fichier de verrouillage à valider devient facile, et nous n'avons plus à nous soucier du fil et npm résultant en différentes constructions. Basé sur cet article de blog , il s'agit d'un changement auquel nous ne devrions pas nous attendre de bientôt (l'article décrit également les différences entre yarn.lock et package-lock.json.
Je pensais à la même question. Voici mes pensées, espérons que cela aide:
La documentation de npm package-lock.json dit ce qui suit:
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.
C’est génial car cela empêche l’effet "Fonctionne sur ma machine".
Sans ce fichier, si vous npm install --save A, npm ajoutera "A": "^1.2.3" à votre package.json. Lorsque quelqu'un d'autre exécute npm install sur votre projet, il est possible que la version 1.2.4 de A ait été publiée. Comme il s’agit de la dernière version disponible satisfaisant la plage semver spécifiée dans votre package.json, il installera cette version. Mais que se passe-t-il si un nouveau bogue est introduit dans cette version? Cette personne aura un problème que vous ne pouvez pas reproduire car vous avez la version précédente, sans aucun bogue.
En corrigeant l'état de votre répertoire node_modules, le fichier package-lock.json évite ce problème car tout le monde disposera des mêmes versions de tous les packages.
Mais que se passe-t-il si vous écrivez et publiez un module npm? La documentation dit ce qui suit:
Un détail clé 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.
Ainsi, même si vous le commettez, lorsque l'utilisateur installe votre module, il/elle ne recevra pas le fichier package-lock.json, mais uniquement le fichier package.json. Donc, npm installera la dernière version qui correspond aux semver plages de toutes vos dépendances. Cela signifie que vous voulez toujours tester votre module avec ces versions de vos dépendances, et non avec celle que vous avez installée lorsque vous avez commencé à écrire votre module. Donc, dans ce cas, package-lock.json est clairement inutile. De plus, cela peut être agaçant.
Voici ma règle de base: si vous travaillez sur une application, validez le (s) fichier (s) verrouillé (s). Si vous maintenez une bibliothèque, ajoutez-la à votre liste ignorée. Dans les deux cas, vous devez utiliser des plages semver précises dans package.json. Yehuda Katz ( mis en cache ) a très bien expliqué le moment de commettre Gemfile.lock (fichier de verrouillage de Ruby) et le moment opportun. Au moins, lisez la section tl; dr.
Ces fichiers sont gérés par vos outils. Par conséquent, si vous utilisez le fil, vous pourrez effectivement mettre à jour le package-lock.json– Je suppose que valider les deux fichiers fonctionne correctement.
Je pense que le plus important pour votre utilisateur est package-lock.json (par exemple, je n’utilise pas de fil), donc celui-ci doit être engagé.
Pour le yarn.lock, cela dépend si vous travaillez seul ou en équipe. Si solo, alors je suppose qu'il n'est pas nécessaire de le commettre. Si vous (envisagez de) travailler en équipe, alors vous devriez probablement l'engager, au moins jusqu'à ce que le fil le supporte ????
Je suppose que l'équipe de fil va finalement arrêter d'utiliser yarn.lock et utiliser package-json.lock à la place, à ce moment-là, cela deviendra plus simple ????
Vous avez raison! Autoriser l'utilisation de npm et yarn va entraîner des problèmes. Jetez un oeil à cet article .
Actuellement, , nous prévoyons d'ajouter quelques avertissements aux utilisateurs qui utilisent à la fois
yarnetnpmdans le même référentiel à installer. paquets.Nous vous recommandons vivement de supprimer le fichier
package-lock.jsonsi vous décidez d'utiliser du fil afin d'éviter toute confusion future et d'éventuels problèmes de cohérence.
Vous ne voudrez peut-être pas à la fois npm et yarn comme gestionnaire de paquets.
Non, l'utilisation simultanée des deux fichiers de verrouillage entraînera le plus souvent des incohérences dans votre arborescence de dépendances, notamment lors de la collaboration au sein d'une équipe. Ignorer un verrou ou l'autre est une solution simple. Assurez-vous simplement que votre équipe comprend et accepte ce changement.