The savior amidst the chaos of dependency updates - Dependabot
4 min read
PreviousWhy doesn't Dependabot update package.json?NextWhy project's local setup instructions are not part of README?
Last updated
4 min read
Last updated
I briefly touched on Dependabot in this section, but now it's time to dive deeper into the topic.
So, you have a list of dependencies. Sometimes it's short, sometimes it's a mile long.
But the big question is, how do you keep those dependencies up-to-date?
Sure, that's one approach, reacting to warnings that pop up post-install.
But this mainly applies to security updates.
What about regular dependency updates, like bumping from a patch version to a minor version, or from a minor version to a major version, without security concerns?
Dependabot is GitHub's solution for automated dependency updates, covering a wide range of programming languages including Ruby, JavaScript, Python, and many more.
All it takes is adding a dependabot.yml config file to your .github repo directory.
Here's what that might look like:
Pretty straightforward, right?
Now, you might wonder: "Okay, automated pull requests sound great, but what if we have tons of dependencies? Will it flood our repo with individual pull requests for each one?"
Yes, that's exactly what would happen. And at exile.watch, with our multitude of dependencies spread across projects, that could easily become overwhelming.
So, am I suggesting that every project gets bombarded with a barrage of pull requests on a weekly (or whatever interval you set) basis for every single dependency update?
By default, yes, Dependabot opens a separate pull request for each dependency update.
But here's the game-changer:
Group updates are a lifesaver, especially for those managing extensive dependency lists.
This relatively new feature was long requested and for good reason.
It allows you to group sets of dependencies (by package manager) so that Dependabot can open a single pull request to update multiple dependencies simultaneously.
Even with grouped updates, if there's a security concern with one of the packages, Dependabot will still prioritize a separate pull request to address the vulnerability promptly, ensuring you're always informed of potential risks.
Here's an example dependabot.yml that exile.watch uses:
You might notice the registries field:
By default, when using the npm registry, there's no need to specify the registry.
However, since exile.watch has chosen to host packages on GitHub's NPM registry, we needed to include this field.
In the case of the crucible project, I've opted for grouping all internal dependencies. Meanwhile, for the splinters project, the strategy is to group updates by config dependency:
And here's the result—grouped pull requests in action:
With this approach, managing our dependencies suddenly feels like a walk in the park, and the once daunting architecture, brimming with countless dependencies, doesn't seem so scary anymore :).
Author: Sebastian Krzyżanowski About exile.watch: https://docs.exile.watch/ Github: https://github.com/exile-watch Visit https://exile.watch/ to experience it first hand
