Florian Munz, Co-Founder at Depfu

Continuing our quest on reducing the amount of PRs: What if grouping or bundling updates together does make sense for certain types of dependencies?

We recently shipped a few options for you to try that on your projects:

We think of these as strategies you can use to reduce the amount of PRs you get from Depfu. By default we will continue to send individual PRs, but depending on how you structure and treat your dependencies, we think it makes sense to give you the option to update certain types of dependencies together.

Grouping development dependencies

While updating dev dependencies might be as much or more work as production dependencies in some cases (test frameworks come to mind), one thing they have in common is that they’re less risky to update. Since they’re not used on your production app, they can’t cause bugs for your users. Also you usually spot errors quite quickly, either directly on your CI system as part of running the build/test or because they’re getting used in the daily workflow of every developer on your team.

Now you can group development dependencies together into a single PR and thus give more focus to your runtime dependencies.

Grouping indirect dependencies

Our strategy for handling indirect dependencies with Bundler so far has been to not update them by default. They still get updates together with their direct dependencies, since that is Bundler’s default. This usually works out fine from our experience, but it results in bundle outdated showing you there are gems that need updating, even if you have applied everything from Depfu.

This has always bothered us and we did build a config option a while ago to also send PRs for indirect dependencies. But it’s disabled by default, since we think the added amount of PRs is not worth the effort for most projects.

With the new options you can now group indirect dependencies together into a single weekly/bi-weekly/monthly PR and it might be a nicer default than simply ignoring it.

Grouping means scheduling

Instead of sending you a PR when a new version gets released, when grouping updates together you have to decide when to actually do the update. Which means scheduling this at a regular interval and collecting all updates that have happened since.

So for grouped updates you can decide how often you want a PR and on what day and time you prefer to get it. Of course, the longer you wait the more dependencies will be updated in a single PR.

Your choice

If you would like to reduce the amount of PRs you get or you would like to give less prominence to development or indirect dependencies, give these new options a try.

We would love hear about how these work for you in practice and if the tradeoff of updating more dependencies in one go is worth the reduced amount of pull requests. Let us know on Twitter or via email.