to lock down which exact versions are in use in your working package

Because in package.json, we normally specify a range of versions for each dependency, chances are we are not going to install the same version each time.

For example, we may have added a package when it is on version 1.0.0. By default, it'll show up in our package.json as ^1.0.0, meaning it accepts anything above that up until 2.0.0. Two weeks later, the package releases a new version 1.0.1, and if we run yarn at another machine then, it'll install that version because it is accepted by ^1.0.0 also.

What yarn.lock does is that it will take note which exact version we installed by maintaining a version number → actual npm package map. You can go ahead and look at one of the yarn.lock files and you'll see each section noting that information. And you may see version numbers map to a same package. So when you run yarn in your project with yarn.lock, it will try to find that exact version first.

This is why Lockfiles should be committed on all projects, but that article goes beyond this perspective. It bipartite the situation into whether we are developing an app or a library and it first establishes that yarn.lock is very suitable for app development because it's clear that the benefit it brings you - installing the same package versions regardless of newer releases - is desired when we develop an app. It further talks about why it is beneficial for library development to also include yarn.lock in the package.

Sometimes you may want to nuke yarn.lock

I ran into an annoying problem related with node, node sass, sharp, and a few more packages. Root cause is sharp which wasn't happy with Node ≥ 12 before v0.22.1. I won't go into details but this was a situation where in fact you want to flush yarn.lock because after sharp supports Node 12 multiple other packages (and you may not wish to hand pick which they are) had follow up releases that you need to upgrade to as well. But yarn.lock kept them locked down to the versions they were initially installed with. In this case you may want to delete yarn.lock, upgrade packages, yarn again, then commit the new yarn.lock file.