51

I accidentally ran npm install in a project that uses Yarn and noticed that npm created a package-lock.json file.

I know that Yarn spiked in popularity in part because it used a lockfile to produce more reliable and deterministic dependency installations than npm, which for a while only had a crippled shrinkwrap feature, but now I'm not sure what to make of this npm lockfile business and whether there's anything compelling about continuing to use Yarn.

So in the spirit of a previous Q and A on StackOverflow on yarn vs shrinkwrap, I ask the following:

  • Are there any substantial differences between the two package managers in terms of reliability any more?
  • If not, is there any compelling reason to continue using Yarn besides "More emojis. "?
fny
  • 31,255
  • 16
  • 96
  • 127
  • 2
    https://yarnpkg.com/blog/2017/05/31/determinism/ might help. Looks like npm 5 has almost achieved parity with yarn on this respect. – Jonathan Lin Jul 12 '17 at 09:28

1 Answers1

39

On paper, Yarn and NPM 5 look almost equivalent. They both have deterministic lock files and have almost matched each other in functionality. Some would say that Yarn was the catalyst to get NPM innovating.

However, after experiencing NPM 5 for a month, my team decided to move to Yarn.

NPM technically has a "more deterministic" lock file in that there is a theoretical guarantee that across NPM versions, NPM will produce the exact same node_modules folder. On the other hand, Yarn's exact hoisting/ordering of dependencies depends on the Yarn version and could change across Yarn versions. In general, this has very little impact.

Why use Yarn then? Merging & reliability.

Yarn made the slight determinism trade-off to achieve a much simpler yarn.lock file that is easier to merge. If you are a solo-developer, this probably will not impact you, but if you are on a team with multiple collaborators committing dependency changes, it quickly becomes a huge problem. NPM's package-lock is practically un-mergeable and you end up having to re-generate or struggle. On the other hand, with Yarn, merges are easy and predictable.

See: https://yarnpkg.com/blog/2017/05/31/determinism/

As a side note, we also found Yarn to be more reliable on average.

Rajiv Makhijani
  • 3,631
  • 32
  • 31
  • 2
    In regards to the merging, I don't know if I would agree about the "ease" of doing so with yarn.lock. I ran across this issue a few weeks ago, and found this conversation, which bascically says, you _should_ regenerate, but do so in a specific way. https://github.com/yarnpkg/yarn/issues/1776#issuecomment-269539948 – jktravis Sep 22 '17 at 12:13
  • My experience has basically been the opposite of this answer, so I think it's primary a personal opinion. Merging `yarn.lock` was basically impossible as different devs were getting wildly different lock files. The workflow @jktravis suggested seems to be the only reliable approach for both Yarn and NPM lock files, and both are about the same. This answer doesn't seem to really give any concrete answer, but the link is interesting. – Aaron Beall Feb 14 '19 at 00:40