Florian Munz, Co-Founder at Depfu

Of course if we start thinking about reducing the amount of PRs, we also have to consider that doing individual updates might not be the best solution in all situations.

If there is one thing we’ve learned so far at Depfu, it’s that every team works differently. Every project – be it open source or in-house – is in a different situation. And the teams working on these projects all have their unique way of working and constraints.

While we love to be be opinionated and have sensible defaults, we also love listening to customers. And quite a few have told us that grouping updates into a single, recurring PR instead of individual updates is what they prefer.

So today we’re giving everyone that option.

This basically does a weekly (or longer apart) bundle update/npm update on your project and sends you a single PR with everything that’s outdated. You can use version constraints to pin or lock certain dependencies, so that the complicated Rails or React update doesn’t get included every week. You decide at what interval you want this PR: weekly, bi-weekly or every month.

As always, we include everything we know about the update into the PR. Due to size constraints on the pull request body, we’re using a more compact style:

We’ll still send you individual PRs for security related updates as soon as possible, outside of your defined cadence. So you can apply them quicker and easier.

It depends

So when would you choose this over individual PRs? A few considerations:

  • Constant rhythm: Since individual updates come in whenever new versions get released, the amount and cadence depends a lot on when those releases happen. There can be weeks with a lot of updates and weeks with very few. With a single batched PR, you’ll get that PR at whatever cadence you’ve set it to and know that it’s going to be part of that week of work. Or if you run two-week sprints, you know there is going to be one PR handling dependency updates that sprint.

  • Low maintenance mode: For projects with few dependencies and which are not actively worked on all the time, using a single PR to update everything is most likely easier to do and less noise. Small services that do one simple thing or internal tooling are examples where this might make sense.

If you feel like this might be something that could work for your project, please give it a try and let us know how it works out for you!