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?
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?
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.
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."
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."
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).
Dépend de ce qu'est votre projet :
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.
D'autre part, l'absence du fichier de verrouillage dans les projets de bibliothèque influencerait-elle la reproductibilité de leurs tests respectifs?
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 ?
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é.
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.
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.
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.
Mais je vois yarn.lock
être mis à jour de temps en temps, savez-vous pourquoi et quand yarn
le fait?
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.
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.
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).
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.
@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.
@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 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.
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.
0 votes
Connexe: stackoverflow.com/questions/45614973/…
0 votes
Plus d'informations directement des documents de Yarn Les verrous doivent-ils être commités dans le dépôt? Les verrous doivent toujours être stockés avec vos sources de projet - et ce, que vous écriviez une application autonome ou une bibliothèque distribuée.