Yarn: Fils.lock doit-il être traité comme un fichier binaire dans git ?

Non, ça ne devrait pas. Le fichier est en texte brut et il peut y avoir des conflits de fusion dans le fichier que vous devrez peut-être résoudre.

Dans la documentation, il est écrit que le fichier fil.lock ne doit pas être touché pour éviter les problèmes et que seul fil lui-même doit le gérer. Alors comment résoudre un conflit de fusion ?

@kittens est-il la bonne chose à faire en cas de conflit pour supprimer le fichier de verrouillage et réexécuter le fil ? Il me semble que vous obtiendrez ce dont vous avez besoin ?

@dbashford le problème avec le fait de le faire sauter et de yarn upgrade .

@dbashford alors il est plus facile de simplement mettre le fil. verrouiller le fichier dans le gitignore

L'approche qui a fonctionné pour moi jusqu'à présent est la suivante:

git rebase origin/master

Lorsque le premier conflit survient, je récupère le yarn.lock puis relance l'installation

git checkout origin/master -- yarn.lock
yarn install

Cela génère un nouveau yarn.lock basé sur la version origin/master de yarn.lock , mais incluant les modifications que j'ai apportées à mon package.json . Ensuite, il s'agit simplement de :

git add yarn.lock
git rebase --continue

Et je suis de retour en affaires.

Notez que même si vous ne résolvez pas manuellement les conflits de fusion, le fait qu'il s'agisse d'un fichier non binaire signifie que vous pouvez voir les conflits de fusion, ce qui reste une information précieuse.

Connexe, même s'il n'y a pas de conflits de fusion, pouvons-nous toujours supposer que git a fusionné deux versions d'un fichier fil.lock d'une manière qui donne un fichier valide/correct ? Il semble erroné de laisser git mettre à jour le contenu du fichier si fil est le seul outil censé gérer son contenu.

Je ne suis pas sûr que la fusion automatique de YAML aboutira toujours à un fichier valide, d'autant plus :

• Plusieurs versions majeures dans le package qui sont juste à côté les unes des autres dans le fichier de verrouillage
• La première ligne de deux entrées voisines peut changer en même temps tout en se résolvant à la même version ou à une version similaire :

readable-stream@^2.0.0, "readable-stream@^2.0.0 || ^1.1.13", readable-stream@^2.0.2, readable-stream@^2.0.5, readable-stream@^2.2.2:
  version "2.2.2"
  resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.2.2.tgz#a9e6fec3c7dda85f8bb1b3ba7028604556fc825e"
  dependencies:
    buffer-shims "^1.0.0"
    core-util-is "~1.0.0"
    inherits "~2.0.1"
    isarray "~1.0.0"
    process-nextick-args "~1.0.6"
    string_decoder "~0.10.x"
    util-deprecate "~1.0.1"

readable-stream@~2.1.4:
  version "2.1.5"
  resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.1.5.tgz#66fa8b720e1438b364681f2ad1a63c618448c9d0"
  dependencies:
    buffer-shims "^1.0.0"
    core-util-is "~1.0.0"
    inherits "~2.0.1"
    isarray "~1.0.0"
    process-nextick-args "~1.0.6"
    string_decoder "~0.10.x"
    util-deprecate "~1.0.1"

@IanVS Merci pour la procédure pas à pas ! Mais la préoccupation de @idris s'applique toujours à cette solution. Vous finirez par mettre à niveau beaucoup de vos dépendances de cette façon, ce qui peut être inattendu.

@danny-andrews pouvez-vous expliquer comment ?

Lorsque vous effacez yarn.lock et réexécutez yarn install , l'intégralité de yarn.lock est reconstruite avec les versions les plus récentes des dépendances qui satisfont les plages de versions spécifiées dans package.json , effectivement mettre à niveau toute dépendance qui a changé depuis la dernière exécution de yarn install .

C'est pourquoi j'ai suggéré git checkout origin/master -- yarn.lock au lieu de supprimer le yarn.lock . Cela réinitialisera votre yarn.lock à la version sur master, permettant au yarn install de mettre à jour uniquement les packages qui ont changé dans votre package.json (et leurs sous-deps, bien sûr) .

@IanVS oui, c'est la bonne façon de le faire.

Bien que je recommande git checkout -- yarn.lock , qui est plus général et le réinitialise simplement à tout ce qui est validé sur votre branche actuelle.

Bon point, @idris. Je rebase généralement sur master, qui est l'exemple que j'ai utilisé ci-dessus, mais ce ne sera pas toujours le cas.

@IanVS Je n'ai pas compris ce que faisait cette commande. C'est bien mieux que de copier et coller manuellement yarn.lock comme je l'ai fait. Merci d'avoir partagé!

Ceci est lié: #3544

L'approche de @IanVS n'est-elle pas compatible avec le fait que le fichier de verrouillage soit un fichier binaire ? Si je comprends bien l'idée est de ne jamais fusionner, juste jeter ce que vous avez et rejouer votre yarn install au - dessus de tout yarn.lock est déjà présent dans la branche que vous fusionnez dans.

voici mon approche, pour ajouter un script bash

#!/usr/bin/env bash
export GIT_TRACE=1
git checkout origin/master -- Pipfile.lock Pipfile
git commit -m "fetch to branch Pipfile.lock, Pipfile from origin/master" -- Pipfile.lock Pipfile
read  -n 1 -p "Do your changes in Pipfile and press Enter ..."
pipenv lock --clear
git commit -m "re-apply changes to Pipfile.lock, Pipfile" -- Pipfile.lock Pipfile
echo "Done"