Yarn: Dois-je mettre fil.lock dans .gitignore ?

Vous devez ajouter fil.lock à votre git , ne l'ignorez pas.

Voir https://yarnpkg.com/en/docs/migrating-from-npm

Lorsque vous exécutez yarn ou yarn add <package> , Yarn génère 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 source . Lorsque d'autres personnes commenceront à utiliser Yarn au lieu de npm , le fichier yarn.lock garantira qu'ils auront exactement les mêmes dépendances que vous.

Juste pour être clair - cela s'applique également aux bibliothèques et pas seulement aux applications, car contrairement à npm-shrinkwrap.json seul le yarn.lock du projet de niveau supérieur sera utilisé, n'est-ce pas ? Ainsi, les dépendances de dépendances avec des fichiers yarn.lock ne généreront pas de doublons inutiles. C'est utile pour les bibliothèques, si vous avez des dépendances de développement complexes et que vous voulez que chaque contributeur de votre bibliothèque ait les mêmes configurations de build et de test.

Est-ce correct?

@goenning
Ce n'est peut-être pas toujours la meilleure idée de mettre le fichier fil.lock dans votre référentiel.
Par exemple, j'utilise sinopia. Par conséquent, j'ai un registre npm personnalisé. J'utilise ce registre principalement pour d'autres projets où j'ai des modules privés.
Mais lorsque je pousse un projet public vers un référentiel git, qui n'a que des dépendances publiques, le fil.lock a les mauvais liens vers les dépendances et mon système CI ne parviendra pas à construire le projet.
Les dépendances pointent vers mon référentiel local.
Cela peut également arriver à d'autres développeurs s'ils clonent mon référentiel.
Existe-t-il un moyen de contourner ce problème, à l'exception de placer le fichier fil.lock dans le gitignore ?

De plus, si vous avez un registre npm pré-authentifié, par exemple myget qui représente un proxy pour npm, yarn.lock aura des liens pré-authentifiés vers des packages, ce qui constitue une faille de sécurité majeure 🎉
Cela devrait être documenté quelque part avec une grosse police.

@Pfeifenjoy et si vous
en utilisant git, vous pouvez accéder au référentiel en utilisant la clé de déploiement (via ssh)

@beenotung Je ne suis pas un grand fan de l'utilisation de git en tant que gestionnaire de dépendances, car il est très lent, ne résout pas les dépendances comme je le souhaite et à mon avis, il est préférable d'avoir chaque dépendance dans un seul gestionnaire.

De plus, les dépendances auxquelles je fais référence auront toutes (pas seulement mes propres projets) une adresse différente, car elles sont enregistrées dans mon compte sinopia local. Il serait très fastidieux de référencer tous les modules de nœuds dont dépendent mes projets dans git.
De plus, il est plus simple de supprimer le fichier fil.lock.

@Pfeifenjoy Y a-t-il peut-être un conflit dans ce que vous voulez que le fil fasse ? Si vous souhaitez fournir un moyen de vous assurer que d'autres installations ont vos dépendances, incluez-le - il fonctionne comme prévu. Si vous extrayez des dépôts et des sources privés, vous devez être très prudent quant à la façon dont vous partagez votre code à proprement parler, de la même manière que vous ignoreriez spécifiquement les clés ou les sels d'un dépôt (si vous voulez voir un avertissement sur le fichier readme du projet, je ferais une demande de fonctionnalité/d'extraction).

Le fil devrait peut-être donner un avertissement lors de l'exécution, alertant un utilisateur que l'accès à une source authentifiée a été inclus dans le fichier de verrouillage, mais encore une fois, ce serait une demande de fonctionnalité.

@thisolivier semble raisonnable

Juste un mémo.
En raison de https://github.com/yarnpkg/yarn/issues/3330 , si vous vivez en Chine ou dans une autre zone restreinte et que vous créez votre module avec un autre registre (eq taobao), vous devez ajouter yarn.lock à .gitignore et écrivez package-lock = false dans .npmrc.

Voici pourquoi je ne commit pas mon fil.lock : certains modules ont des dépendances natives et ne fonctionneront que pour certaines plates-formes (la plate-forme qui est exactement similaire à celle où le fil.lock est généré).
pour que mes utilisateurs soient satisfaits et que l'installation soit sans bug, je supprime fil - à moins que fil ne fournisse une solution avec une documentation claire sur la façon de résoudre ce problème, je serai d'accord alors.
(écoutez toujours le développeur de l'histoire vraie)

De plus, cela rend vos commits vraiment laids.

Je ne suis pas d'accord avec le commentaire le plus élevé ici :

• si le projet utilise npm, commit package-lock.json dans le repo et gitignore yarn.lock
• si le projet utilise du fil, commit yarn.lock dans le repo et gitignore package-lock.json

C'est-à-dire que vous ne devez _pas_ toujours commiter laine.lock dans le repo , et pour répondre à la question d'OP, oui, vous voudrez peut-être l'ajouter à .gitignore .

Lorsque d'autres personnes commenceront à utiliser Yarn au lieu de npm, le fichier fil.lock garantira qu'elles auront exactement les mêmes dépendances que vous.

Tout d'abord, non, ce ne sera pas le cas - uniquement si vous n'utilisez que le registre public npm. Pire encore, si vous n'êtes pas authentifié auprès de votre organisation privée en fil (même si vous êtes toujours en npm) et qu'un package du même nom existe dans le registre public, il installera simplement le mauvais sans invite. Il serait déroutant de savoir pourquoi votre fil s'installe sans erreur, alors que l'application ne fonctionne pas lorsque vous utilisez du fil, mais qu'elle le fait lorsque vous utilisez npm.

Deuxièmement, de nombreuses bases de code _n'utilisent pas_ le fil. Il ne s'agit pas de "quand ils passent au fil". Presque tous mes services de nœuds et serveurs Web de base utilisent npm sans projet de passer à fil. J'aime le fil avec React, c'est à peu près tout.

Comme @Pfeifenjoy mentionné ci-dessus :

J'ai un registre npm personnalisé. J'utilise ce registre principalement pour d'autres projets où j'ai des modules privés

Mais lorsque je pousse un projet public vers un référentiel git, qui n'a que des dépendances publiques, le fil.lock a les mauvais liens vers les dépendances et mon système CI ne parviendra pas à construire le projet.

^ Une autre chose, même lorsque vous le résolvez localement, vous devez incorporer la solution dans le yaml ou n'importe quelle configuration pour CI et n'importe où ailleurs vous lancez l'application - une sorte de logique qui peut dire quand utiliser quel registre et quelle commande - semble ennuyeux et inutile

Une autre chose - si vous encouragez tout le monde à toujours engager yarn.lock dans le référentiel et à ne jamais l'ignorer, les développeurs commenceront à utiliser fil dans un référentiel qui repose déjà fortement sur npm. Même dans les cas où cela fonctionne bien, il y aura des redondances dans les 2 fichiers de verrouillage, et cela ouvrira la porte à l'enfer des dépendances. Et vous savez qu'un développeur va commettre une ligne yarn.lock ~25k