Hi Folks
My team is currently battling a tsunami of renovate PRs for npm package upgrades. We are using renovate to help automate package upgrades to ensure that we are always on the latest version which in turn helps to improve our security posture.
However, over the past 6 to 12 months it has come to a point where we are struggling to keep up with fixing the broken builds due to a renovate PR trying to upgrade a package.
Some ideas we have thought of to try and combat this are:
- Create a culture of everyone spending an hour or two every morning working on renovate PRs.
- Reduce the number of repos we have (we have quite a few) by merging some into mono-repos, thereby allowing us to share more packages between projects reducing the number of PRs.
- Focus on the package upgrades raised by Snyk instead of renovate as security is our highest priority.
- Create a team culture of, if you are working in a repo, make sure you resolve all renovate PRs before releasing to prod.
Each option has pros and cons, for example, option 1 may not scale well, option 2 could mean that although a package upgrade works for one project in the mono-repo it may not work for another thereby delaying the upgrade for all projects in the repo, or the added complexity of being able to deploy projects in a mono-repo individually. Option 3 means that some packages can be far behind making a future upgrade require a bigger jump between versions. Option 4 means that seldom touched repos don't get upgraded as frequently resulting in a similar problem to option 3. Therefore,a combination of these options, or other options would be require.
I'm keen to learn what strategies others use to keep their package upgrades under control and ensure that your code remain secure.
Top comments (1)
We eventually went with consolidating more than 20 repositories into just 2 monorepos. This allows approve a single rennovate PR for all impacted projects. It also allows us to fix breaking changes in a single repo and again raise one PR instead of having to apply the same fix across multiple repositories.
We also created wrappers for dependencies that we've identified as frequently containing breaking changes. These wrappers abstract the functionality we use and means that when a breaking change comes in it's contained within the wrapper which means that we simply release a new wrapper with an unchanged interface and then upgrade each project that uses the wrapper to the latest version. This means that as far as the consuming project is concerned nothing has changed but within the wrapper changes have been made to make the new version of the dependency compatible.
Both of these strategies have helped us to efficiently manage our dependency upgrades and keep the work to a minimum.