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
Was this helpful?
4 min read
Last updated
Was this helpful?
I briefly touched on Dependabot in , but now it's time to dive deeper into the topic.
So, you have a list of . 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?
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?"
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?
But here's the game-changer:
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.
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 :).
?
is GitHub's solution for automated dependency updates, covering a wide range of programming languages including Ruby, JavaScript, Python, .
All it takes is adding a config file to your .github repo directory.
Yes, that's exactly what would happen. And at , with our multitude of dependencies spread across projects, that could easily become overwhelming.
.
are a lifesaver, especially for those managing extensive dependency lists.
This feature was long requested and for good reason.
Even with grouped updates, if there's a security concern with one of the packages, to address the vulnerability promptly, ensuring you're always informed of potential risks.
Here's an example dependabot.yml that uses:
However, , we needed to include this field.
In the case of the project, I've opted for grouping all internal dependencies. Meanwhile, for the project, the strategy is to group updates by config dependency:
And here's the result—:
Author: About exile.watch: Github: Visit to experience it first hand
