571 votes

Dois-je commiter le fichier yarn.lock et à quoi sert-il ?

Yarn crée un fichier yarn.lock après avoir effectué un yarn install.

Cela doit-il être committé dans le dépôt ou ignoré? À quoi sert-il?

4 votes

À mon avis, cette question (et la plupart des réponses ci-dessous) est incomplète en raison de l'absence de la question de savoir, "Comment et quand devrions-nous régénérer le fichier yarn.lock ?"

4 votes

Est-ce que tu sais maintenant comment et quand?

0 votes

@MarkHu l'a trouvé ici: yarnpkg.com/lang/fr/docs/yarn-lock/#toc-managed-by-yarn Donc en gros: Votre fichier yarn.lock est généré automatiquement et doit être géré entièrement par Yarn. Lorsque vous ajoutez/mettez à niveau/supprimez des dépendances avec le CLI Yarn, il mettra automatiquement à jour votre fichier yarn.lock.

553voto

ckuijjer Points 121

Oui, vous devriez le vérifier, voir Migration depuis npm

À quoi cela sert-il?
Le client npm installe les dépendances dans le répertoire node_modules de manière non déterministe. Cela signifie qu'en fonction de l'ordre dans lequel les dépendances sont installées, la structure d'un répertoire node_modules peut être différente d'une personne à l'autre. Ces différences peuvent causer des bugs du type ça fonctionne sur ma machine qui prennent beaucoup de temps à résoudre.

Yarn résout ces problèmes de versionnage et de non-déterminisme en utilisant des fichiers de verrouillage et un algorithme d'installation qui est déterministe et fiable. Ces fichiers de verrouillage fixent les dépendances installées à une version spécifique et garantissent que chaque installation aboutit à la même structure de fichiers exacte dans le répertoire node_modules sur toutes les machines.

48 votes

Belle trouvaille. J'ai trouvé ce qui suit dans leur documentation qui répond à la question "à quoi ça sert?": "Le client npm installe les dépendances dans le répertoire node_modules de manière non déterministe. Cela signifie qu'en fonction de l'ordre d'installation des dépendances, la structure d'un répertoire node_modules peut être différente d'une personne à une autre. Ces différences peuvent causer des bugs du type "ça marche sur ma machine" qui prennent beaucoup de temps à résoudre."

19 votes

Continué : "Yarn résout ces problèmes liés à la version et à la non-déterminisme en utilisant des fichiers de verrouillage et un algorithme d'installation qui est déterministe et fiable. Ces fichiers de verrouillage fixent les dépendances installées à une version spécifique et garantissent que chaque installation aboutit à la même structure de fichiers exacte dans node_modules sur toutes les machines."

1 votes

Au lieu de dire "aucun fichier de verrouillage trouvé", il devrait juste dire "Génération du fichier yarn.lock". Duh :) Ce n'est pas une erreur, mais l'ancien sonne comme une erreur. Et le second sera assez alarmant pour quiconque se trouve dans le scénario inverse (où ils s'attendent à avoir un fichier yarn.lock, mais apparemment ne l'ont pas).

150voto

VoxPelli Points 778

Dépend de ce qu'est votre projet :

  1. Votre projet est-il une application ? Alors : Oui
  2. Votre projet est-il une bibliothèque ? Si oui : Non

Une description plus détaillée de ceci peut être trouvée dans cette question GitHub où l'un des créateurs de Yarn dit par exemple :

Le package.json décrit les versions souhaitées par l'auteur d'origine, tandis que yarn.lock décrit la configuration la plus récente connue pour une application donnée.

Seul le fichier yarn.lock du projet de niveau supérieur sera utilisé. Donc à moins que votre projet soit utilisé de manière autonome et non installé dans un autre projet, il n'est pas utile de commettre un fichier yarn.lock – il reviendra toujours au fichier package.json de transmettre les versions des dépendances que le projet attend.

10 votes

D'autre part, l'absence du fichier de verrouillage dans les projets de bibliothèque influencerait-elle la reproductibilité de leurs tests respectifs?

1 votes

Si je lis correctement votre description, alors "Votre projet est-il une bibliothèque ?" pourrait être répondu par "Si vous le souhaitez". Cela ne semble pas avoir d'inconvénients, mais pourrait être utile si vous avez des devDependencies complexes et que vous voulez que chaque développeur de votre librairie ait les mêmes scripts de construction et de tests. Non ?

6 votes

Comme le fichier de verrouillage ne sera pas respecté pour les utilisateurs de votre bibliothèque, s'appuyer sur celui-ci lors du développement de la bibliothèque pourrait donner une fausse impression de sécurité.

91voto

Juriy Points 1315

Je vois qu'il s'agit de deux questions distinctes en une. Laissez-moi répondre à toutes les deux.

Faut-il commettre le fichier dans le dépôt ?

Oui. Comme mentionné dans la réponse de ckuijjer, il est recommandé dans le guide de migration d'inclure ce fichier dans le dépôt. Lisez la suite pour comprendre pourquoi vous devez le faire.

Qu'est-ce que yarn.lock?

C'est un fichier qui stocke les versions exactes des dépendances pour votre projet en même temps que les checksums de chaque paquet. C'est la façon de Yarn d'assurer la cohérence de vos dépendances.

Pour comprendre pourquoi ce fichier est nécessaire, vous devez d'abord comprendre quel était le problème derrière le package.json original de NPM. Lorsque vous installez le paquet, NPM stockera la plage des révisions autorisées d'une dépendance au lieu d'une révision spécifique (semver). NPM essaiera de mettre à jour la dépendance vers la dernière version disponible dans la plage spécifiée (c'est-à-dire des mises à jour de correctifs non rompues). Il y a deux problèmes avec cette approche.

  1. Les auteurs de dépendances peuvent publier des mises à jour de version de correctif tout en introduisant en réalité un changement rompant qui affectera votre projet.

  2. Deux développeurs exécutant npm install à des moments différents peuvent obtenir des ensembles de dépendances différents. Ce qui peut provoquer un bug qui n'est pas reproductible sur deux environnements exactement identiques. Cela peut causer des problèmes de stabilité de compilation pour les serveurs CI, par exemple.

Yarn, quant à lui, choisit la voie de la plus grande prévisibilité. Il crée le fichier yarn.lock pour sauvegarder les versions de dépendances exactes. En ayant ce fichier en place, Yarn utilisera les versions stockées dans yarn.lock au lieu de résoudre les versions à partir de package.json. Cette stratégie garantit que aucun des problèmes décrits ci-dessus ne se produisent.

yarn.lock est similaire à npm-shrinkwrap.json qui peut être créé par la commande npm shrinkwrap. Consultez cette réponse expliquant les différences entre ces deux fichiers.

1 votes

Mais je vois yarn.lock être mis à jour de temps en temps, savez-vous pourquoi et quand yarn le fait?

1 votes

Problèmes de Yarn #4379 et #4147 suggèrent que yarn met à jour yarn.lock dans de nombreux cas, y compris lors de l'exécution de yarn install sans modifications de package.json. Utiliser yarn install --frozen-lockfile comme suggéré dans Pourquoi l'exécution de yarn sur Windows modifie-t-elle yarn.lock (ou le configurer via .yarnrc) semble être la meilleure solution.

1 votes

Npm a aujourd'hui un package-lock.json et un npm ci. Ce flux de travail est similaire au yarn.lock de yarn et au yarn install --frozen-lockfile.

10voto

jarekwg Points 186

Je suppose que oui, car Yarn versionne son propre fichier yarn.lock : https://github.com/yarnpkg/yarn

Il est utilisé pour la résolution déterministe des dépendances des packages.

7voto

enapupe Points 4127

Oui! yarn.lock doit être vérifié afin que tout développeur qui installe les dépendances obtienne exactement le même résultat! Avec npm [disponible en octobre 2016], par exemple, vous pouvez avoir une version patch (disons 1.2.0) installée localement tandis qu'un nouveau développeur exécutant une nouvelle install pourrait obtenir une version différente (1.2.1).

1 votes

Le comportement du npm que vous avez mentionné dépend de la manière dont vous enregistrez vos dépendances. Si vous enregistrez avec --save-exact lors de l'utilisation de npm, vous pouvez obtenir le même comportement.

4 votes

@AlicanC Je ne pense pas que ce soit si simple. Je crois que yarn (grâce à un fichier de verrouillage engagé) garantira la même version des packages et de toutes leurs dépendances aussi. C'est quelque chose avec lequel NPM a toujours eu des problèmes, car une dépendance d'une dépendance pourrait ne pas être épinglée à une version spécifique, donc une nouvelle installation pourrait entraîner l'ajout de différentes dépendances de niveau inférieur. NPM shrinkwrap était censé résoudre en partie ce problème, mais c'était toujours délicat et très souvent ne fonctionne pas correctement.

0 votes

@nextgentech Si c'est le cas, comment puis-je m'assurer que la dépendance de la dépendance est mise à jour correctement ? Supposons que j'ai un package principal qui a quelques (disons 3) packages dépendants. Je surveillerai les modifications dans mon package principal et je les mettrai à jour dans le package.json. Mais si l'un des 3 sous-packages est mis à jour par eux, comment vais-je obtenir les modifications ? En raison du fichier de verrouillage, ces dépendances ne seront pas mises à jour, n'est-ce pas ?

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X