Managing yarn.lock Efficiently
This is in continuation of my last blog ‘Why do we need lock files’. In the last blog, we saw how important lock files are, this post is about how we can maintain them efficiently.
Before starting with the actual topic, I want to throw some light on a study ‘The law of diminishing return’.
The law says that there comes a point in every development lifecycle where the effort surpasses the amount of output, basically, the ROI is negative. As developers, our responsibility is to make sure our project doesn’t reach the stage early. The current post is one such way to delay the diminishing returns process in front-end projects.
Managing yarn.lock is to keep the lock file thin and updated to make sure there are no vulnerabilities and also not to fall into dependency issues when some new package is added.
These are the following ways in which we can keep our lock file updated. I’ve written the post assuming yarn as a package manager, the same or equivalent features are available with npm also.
1.
yarn audit
It gives a clean tabular view of installed packages with security issues. There are five levels of security vulnerabilities and the ones which need immediate attention are HIGH and CRITICAL.
These can be fixed by either manually upgrading it or using the below command provided by npm. Yarn doesn’t provide it, so it has to be done manually.
npm audit:fix2.
yarn outdated
This is a very useful command to get the installed, wanted, and the latest version of dependencies in the project. Sometimes, we might have dependencies installed versions different than what is required due to resolutions.
We can manually go through the list and chose to upgrade the packages individually.
3.
yarn upgrade
This command is used to update the packages based on the range specified in package.json. ~ will install the latest patch version whereas ^ will install the latest minor version. This will delete the existing yarn.lock and create a new yarn.lock file.
4.
yarn upgrade-interactive
This is a very interesting feature provided by yarn which gives an interactive way to upgrade the dependencies. It is a combination of the above 2 commands yarn outdated and yarn upgrade with some interactive feature to select the dependencies which have to be upgraded.
5.
Dependabot & Renovate
These are dependency management tools available on various code collaboration tools like Github etc.
These tools create automatic PRs on dependency updates. We can schedule the dependencies to check in the tools. The best part is both of these tools are free of cost.
Dependabot creates a PR for every version update and it’s very easy to set up, making it easy to use. However, every PR has to be reviewed and since one PR for every update is created it’s a time-consuming and overwhelming process.
Renovate on the other hand solves the above issues and provides a great set of features too. The update check can be scheduled and automatic PRs will be generated according to the config provided. It also has a feature wherein automatic PR will be merged on the CI/CD pipeline.
Renovate has more adaption and a better feature set than Dependabot.
6.
Snyk
Snyk is a developer-first cloud-native security tool. It covers multiple areas of application security.
It has a CLI which can be integrated into any CI/CD pipeline to scan the projects for updates and security vulnerabilities. However, it’s a paid tool with a freemium licensing model.
7.
Resolutions
There might be a situation in a project where Dependency A wants the latest version of Dependency B, however, the project wants an older version of Dependency B. Generally having 2 versions of dependencies is not an issue but libraries like react recommends not to use 2 versions in the same project. In these cases, resolutions work.
Resolutions only must be used as a last solution. Having a lot of resolutions can result in dependency hell.
"resolutions": {
"react": "16.14.0",
"react-dom": "16.14.0",
},Recommendations
- Integrate Renovate on your code collaboration tool. It’s really helpful and doesn’t consume much of the developer’s time.
- If you don’t want Renovate, then run yarn audit and yarn upgrade every 30 days once either manually or integrate it in the CI/CD pipeline.
- Run yarn upgrade-interactive to check major updates and upgrade the packages.
- Use resolutions only as the last resort.
