Question: How do you keep on top of the endless renovate PRs?

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:

1. Create a culture of everyone spending an hour or two every morning working on renovate PRs.
2. 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.
3. Focus on the package upgrades raised by Snyk instead of renovate as security is our highest priority.
4. 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.