Introduction
Knowing how to read a yarn.lock file is important: it lists the packages that your application will end up using. Sure, your dependencies are listed in your package.json, it only lists your direct deps, not the deps of your deps.
So, if you really care about your app, you should be able to read this lock file, and here is another post about this:
If you spot something weird in the lockfile, this article will tell you how to fix it.
- Problem
- Solutions
- Manually editing the lock file
- The resolutions field
- Removing the yarn.lock file
- yarn dedupe (recommended)
- Bonus: listing all versions of a package
- Yarn 1
- Yarn 2+
- Conclusion
Problem
Note: I'll use the semver syntax, more information on it here: https://jubianchi.github.io/semver-check/.
Let's say you depend on a module A that itself depends on B with the version ^1.1.1. When A will be installed, yarn will resolve the latest version of B matching this version range (let say here 1.1.4). Now you'll have in your lock file something like: "A depends on B@^1.1.1, resolved resolved to 1.1.4".
Later, you want to install a package C, depending on B@^1.1.5. And when C is added, [email protected] just came out. So you end up with [email protected] AND [email protected] in your node_modules.
You ended up here:
But ideally, you should end up like that:
The behaviour is indeed intended: the main goal of lock file is to ensure that your dependencies won't change if you don't ask for it. As you didn't ask for an update of A, it shouldn't update neither it nor its dependencies. And as updating B from 1.1.4 to 1.1.5 could introduce some regression, yarn won't update it.
Real world example: you are using create-react-app, and you want to also to use xo, as both come with their own version of ESLint pre-installed, you could end up with 2 ESLint installed.
Solutions
Manually editing the lock file
I personally really like this solution, as this is the one that allows you to fully manipulate the resolution mechanism.
With our previous example, we should have something like the following in the yarn.lock file:
"B@^1.1.1": version "1.1.4" resolved "https://registry.yarnpkg.com/B-1.1.4.tgz#???" integrity sha512-???=="B@^1.1.5": version "1.1.5" resolved "https://registry.yarnpkg.com/B-1.1.5.tgz#???" integrity sha512-???==
We can simply edit the file, and merge the 2 versions like that:
"B@^1.1.1", "B@^1.1.5": version "1.1.5" resolved "https://registry.yarnpkg.com/B-1.1.5.tgz#???" integrity sha512-???==
Once this has been changed, we just have to run yarn install and 💥, [email protected] will no longer be installed, only [email protected].
The resolutions field
Yarn comes with a custom resolutions field you can set in your package.json
{ "resolutions": { "B": "1.1.5" }}
This will force all versions of B to resolve to this one version 1.1.5.
I don't like this approach, as it'll force all versions (even incompatible ones like a potential v2 that could also be used in your deps) to be updated to this unique one. So I'd reserve this for modules you know cannot exist in multiple versions, but I wouldn't use it otherwise.
Removing the yarn.lock file
If you remove the lock file completely and then run yarn install, yarn will re-resolve all versions to the latest allowed by their specified ranges, and thus fix all those duplicated deps.
I don't recommend doing that as not all packages respect the semver convention. So you could introduce a lot of regressions in your code.
yarn dedupe (recommended)
If you're using yarn 2+, you have access to the command yarn dedupe B (to dedupe all the B packages).
If you're running on yarn 2+, I strongly recommend using this, as it's the easiest and safest method of all of those listed here.
https://yarnpkg.com/cli/dedupe
Bonus: listing all versions of a package
Yarn 1
If you using yarn 1, you can use yarn list --pattern <package-name> to see all the different versions (and where they are coming from) of a package:
https://classic.yarnpkg.com/en/docs/cli/list
Yarn 2+
Yarn berry (version 2 and above), has the command yarn why (it already existed in yarn 1, but the output was completely different).
The main difference between yarn list in yarn 1 and yarn why in yarn 2+ is that, in addition to having the version installed + the parent that required this package, you also have the version ranges that were requested each time.
Also, the tree is flatten here to only have the most meaningful information. But if you want to have a deep tree (like in yarn 1), you can run yarn why <package> -R:
Conclusion
When working on removing duplicated packages, knowing how to read and modify your yarn.lock file is quite empowering.
And if you're running yarn 2+, you can just use yarn dedupe <package>, which will save you a lot of work.
