Dependabot has historically been on the receiving end of many jokes and memes, from the world’s top Hacktoberfest participant to the occasional onslaught of inboxes when a widely popular package receives a security update.
But buried in there was something important and highly useful that can help package maintainers and projects more sanely deal with the never-ending updates of dependencies.
Like most things, it just needs a little configuration.
What is Dependabot?
Dependabot is a feature of GitHub that allows developers to automatically receive dependency updates in the form of Pull Requests to their repository.
One of the original ways of using this was by simply opting into security updates, which you still can, but it’s not the only use case that makes Dependabot powerful.
Similar to GitHub Actions and other GitHub features, you can configure Dependabot to trigger updates to exactly the dependencies you want in whatever frequency you’d like, so whether you want a monthly reminder or want to be on top of every fix, you have both options.
Opting into npm Dependency Updates
To get started, we’ll first need a new file in our GitHub project located at
Inside, we’ll want to specify our configuration:
version: 2 updates: - package-ecosystem: "npm" directory: "/" schedule: interval: "weekly"
Here we’re specifying we want to use the version 2 configuration format and we’re opting into weekly updates in the npm package ecosystem for the
/ directory, which is basically any package in the project.
With this file saved, Dependabot will now work in the background and if one of our dependencies is updated within the weekly check, we’ll swiftly receive a pull request with that update.
The PR includes a bump to not only the version in
package.json but additional updates your lockfile for whatever package manager you’re using whether that’s npm or something like yarn.
This is really great, but if you’re dealing with a lot of dependencies, this can get chatty. If you’re dealing with a lot of dependencies in a lot of different repositories, this can get overwhelming.
Targeted Dependency Updates
Instead of updating all the things, we can think about what dependencies are critical to be updated weekly or daily, and target those in our Dependabot checks.
In my library Next Cloudinary, I rely on (and maintain) a shared set of core utilities to generate URLs separately to be used in other similar libraries and whenever I update that package, I want to be sure Next Cloudinary and any other library depending on it also gets updated.
But I also know that I don’t necessarily need weekly updates to all of the other packages I rely on, so why not just target my utility packages?
To do this, I can use a similar format as before, but only “allow” certain packages:
version: 2 updates: - package-ecosystem: "npm" directory: "/" schedule: interval: "weekly" allow: - dependency-name: "@cloudinary-util/url-loader" - dependency-name: "@cloudinary-util/util"
By only allowing those two dependencies, Dependabot will only
bug help me with Pull Request if they have updates, where I can make sure it looks good and ship.
But honestly, even if I wanted to make sure my other dependencies occasionally got updated, I can do that too!
I can specify two different update options:
version: 2 updates: - package-ecosystem: "npm" directory: "/next-cloudinary" schedule: interval: "weekly" - package-ecosystem: "npm" directory: "/" schedule: interval: "daily" allow: - dependency-name: "@cloudinary-util/url-loader" - dependency-name: "@cloudinary-util/util"
Where here, I check weekly for ANY dependency updates, but I check daily for just those two packages.
Validating Dependabot Updates
But while we’re automating the generation of the dependency update, we’re missing a critical part, which is validating that the update didn’t just completely break our package. We’re not about to ship this thing without some checks in place right? …RIGHT?
Depending on the project that’s getting updated you have a few options.
Tests are an obvious answer. You should be writing tests including unit, end-to-end, and even some visual testing for websites and apps. But not only should you be writing tests, you should be automating your tests with tools like GitHub Actions, which will give us a big benefit here in automatically testing our new changes.
This will make you feel good that something’s validating the changes. Our code is working, at least whatever we wrote a test for, but automated tests aren’t a replacement manual testing, particularly if you’re dealing with a website or app.
When deploying to services like Vercel, Netlify, or any other modern platform, you automatically get deploy previews, which handily show up on that same status check UI on your Pull Request.
That means we can pop open the deployment with our new dependencies and actually validate that nothings broken, giving us full confidence that our dependency update is working properly without ever leaving our browser.
Automating Routine Code Tasks
Dependabot is just one tool we’re able to use to automate our routine code tasks and we can see that while small in the grander scheme of things, will ultimately save us time and help us to ensure that we’re delivering reliable apps with the latest patches and features.
The more you invest in automating your downstream tasks, including the tests and other things like linting, the more you create a realistic environment for being able to smoothly update your package dependencies.