Should yarn.lock be treated as a binary file in git?

[AntonNiklasson]

http://stackoverflow.com/questions/40532940/should-yarn-lock-be-treated-as-a-binary-file-in-git [CLOSED]

[sebmck]

No it shouldn't. The file is plain text and there can be merge conflicts in the file that you may need to resolve.

[MatteoGabriele]

In the documentation is written that the yarn.lock file should not be touched to avoid problems and only yarn itself should deal with it. Then how I resolve a merge conflict?

[dbashford]

@kittens is the right thing to do when there are conflicts to blow away the lock file and re-run yarn? Seems to me that'd get what you need?

[idris]

@dbashford the problem with blowing it away and re-running yarn is that you'll get more changes than you wanted. For example, tilde versions will be upgraded, even though you didn't run yarn upgrade.

[MatteoGabriele]

@dbashford then it's easier to just put the yarn. lock file in the gitignore

[IanVS]

The approach that has worked for me so far is this:

git rebase origin/master

When the first conflict arises, I checkout the yarn.lock then re-perform the installation

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

This generates a new yarn.lock based on the origin/master version of yarn.lock, but including the changes I made to my package.json. Then it's just a matter of:

git add yarn.lock
git rebase --continue

And I'm back in business.

[ljharb]

Note that even if you're not manually resolving the merge conflicts, having it be a non-binary file means you can see the merge conflicts, which is still valuable information.

[mmcgahan]

Related, even if there are no merge conflicts, can we always assume that git has merged two versions of a yarn.lock file in a way that results in a valid/correct file? It seems wrong to let git update the contents of the file at all if yarn is the only tool that is supposed to manage its content.

[alexkrolick]

I'm not sure that automerging YAML will always result in a valid file, especially given:

• Multiple major versions in the package that are right next to each other in the lockfile
• The first line of two neighboring entries can change at the same time while resolving to the same or similar version:

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"

[danny-andrews]

@IanVS Thanks for the walkthrough! But @idris's concern still applies to this solution. You will end up upgrading a lot of your dependencies this way, which may be unexpected.

[IanVS]

@danny-andrews can you explain how?