In this tutorial, you will learn how about Yarn resolutions. One benefit of using yarn is that it creates a repeatable and deterministic installation process. When you install your project's dependencies a lock file is generated. When you commit the lock file and another developer pulls that file. They will have a blue-print of the order and the package versions that you successfully used to install the application.
To make working with yarn easier it is common to install dependencies with the ^ or ~ flag. To refresh your memory, ^version means that during installation yarn will install that package and auto-bump it to include all future minor/patch versions that it might find. So myPackage^1.0.1 will auto-bump until myPackage^1.1.0 is released.
Once in awhile our build-pipeline will randomly fail. The failing test will usually be in an area of the code completely unrelated to my changes. The reason for the failure is usually down to this auto-bumping and which package yarn chooses to run. Let's say you have this chain:
packageOne has these dependencies
Both my-package and packageOne have references to packageTwo. The reason for the failed build is that both packages reference different versions. If you encounter an issue like this you can use a resolution.
Using a resolution allows you to explicitly override package versions inside your dependencies and more importantly sub-dependencies. A resolution tells yarn to use that version and not with the version defined within its package.json or a sub-components package.json. You may not need to use resolutions on a daily basis. When you get these sub-dependencies mismatches it can save you a lot of time. Enjoy!