Dois-je livrer les fichiers yarn.lock et package-lock.json ?

Question

Nous utilisons yarn pour toutes nos installations déterministes de pkg mais nous n'empêchons pas l'utilisateur d'utiliser npm - je suppose que le fait d'avoir ces deux fichiers causera des problèmes cependant. L'un d'eux doit-il être ajouté à votre répertoire .gitignore ?

Answer 1

Toujours commiter les fichiers de verrouillage des dépendances en général

En l'état couvert ailleurs, les fichiers de verrouillage des dépendances, qui sont pris en charge par de nombreux systèmes de gestion de paquets (par ex : compositeur y bundler ), doivent être intégrés dans le code de base des projets de fin de chaîne, de sorte que chaque personne qui tente de faire fonctionner ce projet le fasse avec le code de base du projet. exactement l'ensemble des dépendances testées.

Il est moins évident de savoir si les fichiers de verrouillage doivent toujours être livrés dans des paquets destinés à être inclus dans d'autres projets (où des dépendances plus lâches sont souhaitables). Cependant, les deux Fils et NPM (comme couvert par @Cyrille) ignorent intelligemment yarn.lock y package-lock.json respectivement lorsque cela est nécessaire, ce qui rend sûr de toujours livrer ces fichiers de verrouillage.

Donc vous devriez toujours commettre au moins une des yarn.lock o package-lock.json selon le gestionnaire de paquets que vous utilisez.

Devriez-vous livrer à 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 de package.json mais qui génèrent et lisent deux fichiers de verrouillage différents. NPM 5 génère package-lock.json tandis que le fil génère yarn.lock .

Si vous commettez package-lock.json alors vous mettez en place un support pour les personnes qui installent vos dépendances avec NPM 5. Si vous commettez yarn.lock vous mettez en place un support pour les personnes qui installent des dépendances avec Yarn.

Que vous choisissiez de vous engager yarn.lock o package-lock.json ou les deux dépend du fait que ceux qui développent sur votre projet utilisent uniquement Yarn ou NPM 5 ou les deux. Si votre projet est open-source, la chose la plus conviviale à faire pour la communauté serait probablement de commiter les deux et d'avoir un processus automatisé pour s'assurer que yarn.lock y package-lock.json restent toujours synchronisés.

Mise à jour : Yarn a maintenant introduit un import commande qui générera un yarn.lock à partir d'un fichier package-lock.json fichier. Cela pourrait être utile pour garder les deux fichiers synchronisés. (Merci @weakish)

---

Cette question a été longuement discutée dans le cadre du projet Yarn :

• "Idée : supporter package-lock.json de npm 5"
• "Les fichiers de verrouillage concurrents créent une mauvaise interface utilisateur".

Les deux sont maintenant fermés.

Answer 2

Vous devez livrer un fichier de verrouillage de l'arbre de dépendance, mais vous ne devez pas livrer les deux. Cela nécessite également de standardiser soit yarn soit npm (pas les deux) pour construire et développer un projet.

Voici l'article de yarn sur les raisons pour lesquelles yarn.lock devrait être engagé, si vous standardisez sur yarn.

Si vous commettez à la fois le yarn.lock ET le fichier package-lock.json il existe de nombreuses façons pour les deux fichiers de fournir des arbres de dépendances différents (même si les algorithmes de résolution d'arbres de yarn et de npm sont identiques), et il n'est pas trivial de s'assurer qu'ils fournissent exactement la même réponse. Puisque ce n'est pas trivial, il est peu probable que le même arbre de dépendance soit maintenu dans les deux fichiers, et vous ne voulez pas un comportement différent selon que la construction a été faite en utilisant yarn ou npm.

Si et quand le fil passe de l'utilisation yarn.lock a package-lock.json ( question ici ), le choix du fichier de verrouillage à livrer devient alors facile, et nous n'avons plus à nous soucier du fait que yarn et npm donnent lieu à des constructions différentes. Sur la base de cet article de blog il s'agit d'un changement auquel il ne faut pas s'attendre de sitôt (l'article de blog décrit également les différences entre les systèmes de gestion de l'information et les systèmes de gestion de l'information). yarn.lock y package-lock.json .

Answer 3

Je me posais la même question. Voici mes réflexions, j'espère que cela vous aidera :

El documentation npm package-lock.json dit ce qui suit :

package-lock.json est automatiquement généré pour toute opération où npm modifie soit l'arbre node_modules, soit package.json. Il décrit l'arbre exact qui a été généré, de sorte que les installations ultérieures puissent générer des arbres identiques, indépendamment des mises à jour intermédiaires des dépendances.

C'est une bonne chose car cela évite l'effet "fonctionne sur ma machine".

Sans ce fichier, si vous npm install --save A , npm ajoutera "A": "^1.2.3" à votre package.json . Quand quelqu'un d'autre dirige npm install sur votre projet, il est possible que la version 1.2.4 de A a été publié. Puisqu'il s'agit de la dernière version disponible qui satisfait à la fourchette de semver spécifiée dans vos package.json il installera cette version. Mais que se passe-t-il si un nouveau bug 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 bug.

En fixant l'état de votre node_modules répertoire, package-lock.json évite ce problème car tout le monde aura les mêmes versions de tous les paquets.

Mais, que se passe-t-il si vous écrivez et publiez un module npm ? La documentation dit ce qui suit :

Un détail important concernant package-lock.json est qu'il ne peut pas être publié et qu'il sera ignoré s'il est trouvé ailleurs que dans le paquet de niveau supérieur.

Ainsi, même si vous le validez, lorsque l'utilisateur installera votre module, il n'obtiendra pas l'adresse de l'utilisateur. package-lock.json mais seulement le package.json fichier. Ainsi, npm installera la dernière version qui satisfait les plages de semver de toutes vos dépendances. Cela signifie que vous voulez toujours tester votre module avec ces versions de vos dépendances, et non 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 ennuyeux.

Answer 4

Voici ma règle d'or : si vous travaillez sur une application, livrez le(s) fichier(s) verrouillé(s). Si vous maintenez une bibliothèque, ajoutez-la à votre liste d'ignorés. D'une manière ou d'une autre, vous devriez utiliser des plages de semver précises dans le fichier package.json . Yehuda Katz ( en cachette ) a écrit une excellente explication sur le moment où il faut s'engager Gemfile.lock (le fichier de verrouillage de Ruby) et quand ne pas le faire. Lisez au moins la section tl;dr.

Answer 5

Ces fichiers sont gérés par vos outils, donc - en supposant que l'utilisation de yarn mettra effectivement à jour le fichier package-lock.json -Je suppose que l'envoi des deux fichiers fonctionne bien.

Je pense que le plus important pour votre utilisateur est package-lock.json (Moi, par exemple, je n'utilise pas de fil) donc celui-ci a de s'engager.

Pour le yarn.lock cela dépend si vous travaillez seul ou en équipe. Si vous travaillez seul, je suppose qu'il n'est pas nécessaire de l'engager. Si vous travaillez (ou prévoyez de le faire) en équipe, alors vous devriez probablement l'engager, au moins jusqu'au fil. le soutient

Je suppose que l'équipe chargée du filage finira par ne plus utiliser yarn.lock et utiliser package-json.lock au lieu de cela, à ce moment-là, il deviendra plus simple