to lock down which exact versions are in use in your working package
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
^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
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
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