À mon humble avis, cette question (et la plupart des réponses ci-dessous) sont incomplètes en raison de la question manquante, "Comment et quand devrions-nous régénérer le fichier yarn.lock?"
MarkHu
1
Savez-vous maintenant comment et quand?
jayarjo
@MarkHu l'a trouvé ici: yarnpkg.com/lang/en/docs/yarn-lock/#toc-managed-by-yarn Donc en gros:Your yarn.lock file is auto-generated and should be handled entirely by Yarn. As you add/upgrade/remove dependencies with the Yarn CLI, it will automatically update your yarn.lock file.
Yarn générera un fichier yarn.lock dans le répertoire racine de votre package. Vous n'avez pas besoin de lire ou de comprendre ce fichier - il suffit de le vérifier dans le contrôle de code source.
Belle trouvaille. J'ai trouvé ce qui suit dans leurs documents qui répond "à quoi ça sert?": "Le client npm installe les dépendances dans le répertoire node_modules de manière non déterministe. Cela signifie que, selon l'ordre des dépendances installées, la structure d'un node_modules Le répertoire peut être différent d'une personne à l'autre. Ces différences peuvent entraîner des bogues "qui fonctionnent sur ma machine" qui prennent beaucoup de temps à traquer.
rlay3
13
Suite: «Yarn résout ces problèmes de version et de non-déterminisme en utilisant des fichiers de verrouillage et un algorithme d'installation déterministe et fiable. Ces fichiers de verrouillage verrouillent les dépendances installées sur une version spécifique et garantissent que chaque installation aboutit à la même structure de fichiers exacte dans node_modules sur toutes les machines. "
rlay3
Au lieu de dire "aucun fichier de verrouillage trouvé". Il devrait simplement indiquer "Génération du fichier yarn.lock". Duh :) Ce n'est pas une erreur, mais la première sonne comme une erreur. Et ce dernier sera suffisamment alarmant pour quiconque dans le scénario inverse (où ils s'attendent à avoir un fichier yarn.lock, mais apparemment pas).
Alexander Mills
7
J'apprécie que yarn.lock verrouille notre projet sur des versions de package spécifiques, mais je pense que l'utilisation du mot "lock" est malheureuse. Généralement , les fichiers verrouillés (tels que .ldb ) sont un moyen de limiter une ressource à un seul processus à la fois pour éviter la corruption pouvant entraîner des mises à jour. Ces fichiers de verrouillage ne doivent certainement pas être soumis au contrôle de version, ce qui est probablement la source de la plupart des confusions concernant yarn.lock.
Antony
2
Je n'aime vraiment pas l'expression "vous n'avez pas besoin de lire ou de comprendre ce fichier". Il s'agit d'un fichier important pour maintenir votre projet.
Nathan Goings
83
Cela dépend de votre projet:
Votre projet est-il une application? Alors: oui
Votre projet est-il une bibliothèque? Si oui: non
Une description plus détaillée de cela peut être trouvée dans ce numéro de GitHub où l'un des créateurs de Yarn par exemple. dit:
Le package.json décrit les versions prévues souhaitées par l'auteur d'origine, tandis que yarn.lock décrit la dernière bonne configuration connue pour une application donnée.
Seul le yarn.lockfichier du projet de niveau supérieur sera utilisé. Donc, à moins que le projet ne soit utilisé de manière autonome et ne soit pas installé dans un autre projet, il est inutile de yarn.lockvalider un fichier - au lieu de cela, il appartiendra toujours au package.jsonfichier de transmettre les versions des dépendances attendues par le projet.
D'un autre côté, le fait d'avoir le fichier de verrouillage dans les projets de bibliothèque n'influencerait-il pas la reproductibilité de leurs tests respectifs?
E_net4 aime les votes négatifs du
1
Si j'ai bien lu votre description, alors "Votre projet est-il une bibliothèque?" pourrait être répondu par "Si vous voulez". Il 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 bibliothèque ait les mêmes scripts de build et de test. Droite?
Pipo
4
Comme le fichier de verrouillage ne sera respecté pour aucun utilisateur de votre bibliothèque, le fait de vous y fier lors du développement de la bibliothèque pourrait donner un faux sentiment de sécurité
VoxPelli
1
Dart a le même système avec pubspec.yaml et pubspec.lock et recommande le même que dans la réponse. Voir cette question et cette entrée de documentation.
Je vois que ce sont deux questions distinctes en une. Permettez-moi de répondre aux deux.
Devez-vous valider le fichier dans le repo?
Oui. Comme mentionné dans la réponse de ckuijjer, il est recommandé dans le Guide de migration d'inclure ce fichier dans le référentiel. Lisez la suite pour comprendre pourquoi vous devez le faire.
Qu'est-ce que c'est yarn.lock?
Il s'agit d'un fichier qui stocke les versions de dépendance exactes pour votre projet ainsi que les sommes de contrôle pour chaque package. C'est la façon dont le fil assure 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 les NPM d'origine package.json. Lorsque vous installez le package, NPM stocke la plage de révisions autorisées d'une dépendance au lieu d'une révision spécifique (semver). NPM essaiera de récupérer la mise à jour de la dernière version de la dépendance dans la plage spécifiée (c.-à-d. Les mises à jour de correctif sans interruption). 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 un changement de rupture qui affectera votre projet.
Deux développeurs s'exécutant npm installà des moments différents peuvent obtenir le jeu de dépendances différent. Ce qui peut rendre un bogue non reproductible sur deux environnements exactement identiques. Cela peut entraîner des problèmes de stabilité de construction pour les serveurs CI par exemple.
Le fil, quant à lui, emprunte la voie d'une prévisibilité maximale. Il crée un yarn.lockfichier pour enregistrer les versions de dépendance exactes . Ayant ce fichier en place, le fil utilisera les versions stockées dans yarn.lockau lieu de résoudre les versions de package.json. Cette stratégie garantit qu'aucun des problèmes décrits ci-dessus ne se produit.
yarn.lockest similaire à npm-shrinkwrap.jsoncelui qui peut être créé par npm shrinkwrapcommande. Vérifiez 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 yarncela?
jayarjo
1
Les problèmes de fils # 4379 et # 4147 suggèrent que les yarnmises yarn.lockà jour dans de nombreux cas, y compris l'exécution yarn installsans modifications de package.json. Utiliser yarn install --frozen-lockfilecomme suggéré dans Pourquoi l'exécution de Yarn sur Windows change Yarn.lock (ou le configurer via .yarnrc) semble être la meilleure solution.
Lauri Harpf
npm a de nos jours un package-lock.jsonet un npm ci. Ce flux de travail est un fil analogue de yarn.locket yarn install --frozen-lockfile.
utiliser yarn install --frozen-lockfileet NON yarn installpar défaut à la fois localement et sur les serveurs de build CI.
(J'ai ouvert un ticket sur le suivi des problèmes de Yarn pour faire un cas pour faire un comportement par défaut de fichier de verrouillage gelé, voir # 4147 ).
Attention à ne PAS définir l' frozen-lockfileindicateur dans le .yarnrcfichier car cela vous empêcherait de pouvoir synchroniser les fichiers package.json et yarn.lock. Voir le problème de fil associé sur github
Aussi, esp. dans les grandes équipes, vous pouvez avoir beaucoup de bruit autour des changements dans le verrou de fil uniquement parce qu'un développeur configure son projet local.
Installez toutes les dépendances répertoriées dans package.json dans le dossier node_modules local.
Le yarn.lockfichier est utilisé comme suit:
Si yarn.lock est présent et est suffisant pour satisfaire toutes les dépendances répertoriées dans package.json, les versions exactes enregistrées dans yarn.lock sont installées et yarn.lock ne sera pas modifié. Yarn ne vérifiera pas les versions plus récentes.
Si yarn.lock est absent ou n'est pas suffisant pour satisfaire toutes les dépendances répertoriées dans package.json (par exemple, si vous ajoutez manuellement une dépendance à package.json), Yarn recherche les dernières versions disponibles qui satisfont aux contraintes du package .json. Les résultats sont écrits dans yarn.lock.
Si vous voulez vous assurer que yarn.lock n'est pas mis à jour, utilisez --frozen-lockfile.
Si cela est vrai, la seule fois que je peux penser que vous avez à l' utilisation --frozen-lockfileest si quelqu'un package.json mis à jour manuellement sans courir ensuite yarn installet commettre les mises à jour. Un CI peut donc vouloir utiliser cet indicateur, mais les développeurs ne le devraient pas car il cache les problèmes.
jkrehm
@jkrehm Dépend de ce que vous entendez par masquer les problèmes. J'ai eu plus de problèmes avec les yarn.lockfichiers modifiés de manière inattendue introduits par yarn install, soit en gonflant les demandes de tirage, soit en provoquant des conflits de fusion inutiles, ou en tirant une bibliothèque cassée. (Uniquement parce qu'une bibliothèque utilise semvar, cela ne signifie pas qu'un correctif / une mise à jour mineure ne cassera pas votre application - j'y suis allé). Je considère que la mise à jour yarn.lockne devrait être qu'une étape manuelle, c'est pourquoi je compte sur yarn install --frozen-lockfile(et npm cisur les projets npm) même sur ma machine de développement car elle est fiable et déterministe.
k0pernikus
1
Je n'ai jamais eu de problème avec la yarn.lockmise à jour inattendue ( j'utilise depuis octobre 2016 quand il est sorti). Cela a toujours été un utilisateur faisant quelque chose manuellement ou un script post-installation moche. C'est la raison pour laquelle je préfère Yarn à NPM (NPM met à jour tout ce qu'il veut). Je suppose que je me considère chanceux de ne pas avoir rencontré ces problèmes.
jkrehm
5
D'après mon expérience, je dirais que nous devrions valider le yarn.lockfichier. Cela garantira que, lorsque d'autres personnes utiliseront votre projet, elles obtiendront les mêmes dépendances que celles prévues par votre projet.
Lorsque vous exécutez soit yarn soit yarn add, Yarn générera un fichier yarn.lock dans le répertoire racine de votre package. Vous n'avez pas besoin de lire ou de comprendre ce fichier - il suffit de le vérifier dans le contrôle de code source. Lorsque d'autres personnes commencent à utiliser Yarn au lieu de npm, le fichier yarn.lock s'assurera qu'elles obtiennent exactement les mêmes dépendances que vous.
On pourrait soutenir que nous pouvons y parvenir en remplaçant ^par --. Oui, nous le pouvons, mais en général, nous avons vu que la majorité des npmpackages sont livrés avec la ^notation, et nous devons changer la notation manuellement pour garantir la version de la dépendance statique, mais si vous l'utilisez, vous yarn.lockgarantissez par programmation votre version correcte.
Oui! yarn.lockdoit être archivé pour que tout développeur qui installe les dépendances obtienne exactement la même sortie! Avec npm [qui était disponible en octobre 2016] , par exemple, vous pouvez avoir une patchversion (disons 1.2.0) installée localement tandis qu'un nouveau développeur exécutant une nouvelle version installpeut obtenir une version différente (1.2.1).
Le comportement npm que vous avez mentionné dépend de la façon dont vous enregistrez vos dépendances. Si vous enregistrez avec --save-exactlors de l'utilisation de npm, vous pouvez obtenir le même comportement.
AlicanC
4
@AlicanC Je ne pense pas que ce soit aussi simple que cela. Je crois que le fil (via un fichier de verrouillage validé) garantira également la même version des packages et toutes leurs dépendances . C'est quelque chose avec lequel NPM a toujours eu un problème, car une dépendance d'une dépendance peut ne pas être épinglée à une version spécifique, donc une nouvelle installation peut attirer différentes dépendances de niveau inférieur. NPM shrinkwrap était censé résoudre ce problème dans une certaine mesure, mais c'était toujours délicat et très souvent ne fonctionnait pas correctement.
nextgentech
@nextgentech Si dans ce cas, comment puis-je m'assurer que la dépendance de la dépendance est correctement mise à jour. Supposons que j'ai un paquet principal qui a (disons 3) des paquets dépendants. Je vais surveiller les changements dans mon package principal et le mettre à 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?
Pragatheeswaran
Je ne l'ai pas encore beaucoup essayé, mais je pense que c'est là que la yarn upgradecommande entre en jeu. Cette commande mettra à niveau tous les packages et recréera le fichier de verrouillage. Ainsi, par exemple, si vous déployez une application en production et devez installer les dépendances, cela se fera en fonction du fichier de verrouillage extrait du référentiel. Vous ne devez jamais exécuter yarn upgradesauf si vous souhaitez explicitement modifier les informations de dépendance (et donc valider un nouveau fichier de verrouillage).
nextgentech
yarn installn'assurera pas les mêmes versions. Seulement yarn install --frozen-lockfile.
Your yarn.lock file is auto-generated and should be handled entirely by Yarn. As you add/upgrade/remove dependencies with the Yarn CLI, it will automatically update your yarn.lock file.Réponses:
Oui, vous devez le vérifier, voir Migration à partir de npm
la source
Cela dépend de votre projet:
Une description plus détaillée de cela peut être trouvée dans ce numéro de GitHub où l'un des créateurs de Yarn par exemple. dit:
Seul le
yarn.lockfichier du projet de niveau supérieur sera utilisé. Donc, à moins que le projet ne soit utilisé de manière autonome et ne soit pas installé dans un autre projet, il est inutile deyarn.lockvalider un fichier - au lieu de cela, il appartiendra toujours aupackage.jsonfichier de transmettre les versions des dépendances attendues par le projet.la source
Je vois que ce sont deux questions distinctes en une. Permettez-moi de répondre aux deux.
Devez-vous valider le fichier dans le repo?
Oui. Comme mentionné dans la réponse de ckuijjer, il est recommandé dans le Guide de migration d'inclure ce fichier dans le référentiel. Lisez la suite pour comprendre pourquoi vous devez le faire.
Qu'est-ce que c'est
yarn.lock?Il s'agit d'un fichier qui stocke les versions de dépendance exactes pour votre projet ainsi que les sommes de contrôle pour chaque package. C'est la façon dont le fil assure 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 les NPM d'origine
package.json. Lorsque vous installez le package, NPM stocke la plage de révisions autorisées d'une dépendance au lieu d'une révision spécifique (semver). NPM essaiera de récupérer la mise à jour de la dernière version de la dépendance dans la plage spécifiée (c.-à-d. Les mises à jour de correctif sans interruption). 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 un changement de rupture qui affectera votre projet.
Deux développeurs s'exécutant
npm installà des moments différents peuvent obtenir le jeu de dépendances différent. Ce qui peut rendre un bogue non reproductible sur deux environnements exactement identiques. Cela peut entraîner des problèmes de stabilité de construction pour les serveurs CI par exemple.Le fil, quant à lui, emprunte la voie d'une prévisibilité maximale. Il crée un
yarn.lockfichier pour enregistrer les versions de dépendance exactes . Ayant ce fichier en place, le fil utilisera les versions stockées dansyarn.lockau lieu de résoudre les versions depackage.json. Cette stratégie garantit qu'aucun des problèmes décrits ci-dessus ne se produit.yarn.lockest similaire ànpm-shrinkwrap.jsoncelui qui peut être créé parnpm shrinkwrapcommande. Vérifiez cette réponse expliquant les différences entre ces deux fichiers.la source
yarn.lockêtre mis à jour de temps en temps, savez-vous pourquoi et quandyarncela?yarnmisesyarn.lockà jour dans de nombreux cas, y compris l'exécutionyarn installsans modifications de package.json. Utiliseryarn install --frozen-lockfilecomme suggéré dans Pourquoi l'exécution de Yarn sur Windows change Yarn.lock (ou le configurer via.yarnrc) semble être la meilleure solution.package-lock.jsonet unnpm ci. Ce flux de travail est un fil analogue deyarn.locketyarn install --frozen-lockfile.Je suppose que oui, puisque Yarn versionne son propre fichier yarn.lock: https://github.com/yarnpkg/yarn
Il est utilisé pour la résolution déterministe des dépendances de package.
la source
Vous devriez:
yarn install --frozen-lockfileet NONyarn installpar défaut à la fois localement et sur les serveurs de build CI.(J'ai ouvert un ticket sur le suivi des problèmes de Yarn pour faire un cas pour faire un comportement par défaut de fichier de verrouillage gelé, voir # 4147 ).
Attention à ne PAS définir l'
frozen-lockfileindicateur dans le.yarnrcfichier car cela vous empêcherait de pouvoir synchroniser les fichiers package.json et yarn.lock. Voir le problème de fil associé sur githubyarn installpeut muter votre yarn.lock de façon inattendue , ce qui rend caduques les revendications de fils de constructions répétables. Vous ne devez utiliser queyarn installpour initialiser un yarn.lock et le mettre à jour.Aussi, esp. dans les grandes équipes, vous pouvez avoir beaucoup de bruit autour des changements dans le verrou de fil uniquement parce qu'un développeur configure son projet local.
Pour plus d'informations, lisez ma réponse à propos de package-lock.json de npm car cela s'applique également ici.
Cela a également été récemment précisé dans la documentation pour l'installation du fil :
la source
--frozen-lockfileest si quelqu'un package.json mis à jour manuellement sans courir ensuiteyarn installet commettre les mises à jour. Un CI peut donc vouloir utiliser cet indicateur, mais les développeurs ne le devraient pas car il cache les problèmes.yarn.lockfichiers modifiés de manière inattendue introduits paryarn install, soit en gonflant les demandes de tirage, soit en provoquant des conflits de fusion inutiles, ou en tirant une bibliothèque cassée. (Uniquement parce qu'une bibliothèque utilise semvar, cela ne signifie pas qu'un correctif / une mise à jour mineure ne cassera pas votre application - j'y suis allé). Je considère que la mise à jouryarn.lockne devrait être qu'une étape manuelle, c'est pourquoi je compte suryarn install --frozen-lockfile(etnpm cisur les projets npm) même sur ma machine de développement car elle est fiable et déterministe.yarn.lockmise à jour inattendue ( j'utilise depuis octobre 2016 quand il est sorti). Cela a toujours été un utilisateur faisant quelque chose manuellement ou un script post-installation moche. C'est la raison pour laquelle je préfère Yarn à NPM (NPM met à jour tout ce qu'il veut). Je suppose que je me considère chanceux de ne pas avoir rencontré ces problèmes.D'après mon expérience, je dirais que nous devrions valider le
yarn.lockfichier. Cela garantira que, lorsque d'autres personnes utiliseront votre projet, elles obtiendront les mêmes dépendances que celles prévues par votre projet.Du Doc
On pourrait soutenir que nous pouvons y parvenir en remplaçant
^par--. Oui, nous le pouvons, mais en général, nous avons vu que la majorité desnpmpackages sont livrés avec la^notation, et nous devons changer la notation manuellement pour garantir la version de la dépendance statique, mais si vous l'utilisez, vousyarn.lockgarantissez par programmation votre version correcte.Aussi comme Eric Elliott l'a dit ici
la source
Oui, vous devriez le commettre. Pour en savoir plus sur le fichier yarn.lock, reportez-vous aux documents officiels ici
la source
Oui!
yarn.lockdoit être archivé pour que tout développeur qui installe les dépendances obtienne exactement la même sortie! Avec npm [qui était disponible en octobre 2016] , par exemple, vous pouvez avoir unepatchversion (disons 1.2.0) installée localement tandis qu'un nouveau développeur exécutant une nouvelle versioninstallpeut obtenir une version différente (1.2.1).la source
--save-exactlors de l'utilisation de npm, vous pouvez obtenir le même comportement.yarn upgradecommande entre en jeu. Cette commande mettra à niveau tous les packages et recréera le fichier de verrouillage. Ainsi, par exemple, si vous déployez une application en production et devez installer les dépendances, cela se fera en fonction du fichier de verrouillage extrait du référentiel. Vous ne devez jamais exécuteryarn upgradesauf si vous souhaitez explicitement modifier les informations de dépendance (et donc valider un nouveau fichier de verrouillage).yarn installn'assurera pas les mêmes versions. Seulementyarn install --frozen-lockfile.