What I Got Wrong About Dependabot
Why turning it on still left me with outdated, vulnerable dependencies
I used to think Dependabot was a checkbox. Enable it on GitHub, glance at the security tab once in a while, merge the pull requests that looked easy. That felt like being responsible. Alerts were on. A bot was watching. I could get back to writing features.
Then I actually looked at a repo I'd been treating that way. The framework was months behind. Dozens of alerts were sitting open. The only pull requests Dependabot had sent were security bumps, and I'd closed a few of those too because the lockfile had conflicts. I had turned Dependabot on. I had not configured it, and I had not really used it.
Alerts aren't an update strategy
GitHub can warn you about known vulnerabilities without ever keeping your versions current. That's what happened to me. Security updates were enabled. There was no config file in the repo. So Dependabot only showed up after something was already a CVE, not when a quiet patch had been sitting on npm for weeks.
I also treated those security PRs like noise. A framework bump would conflict with something else. I'd close it. A slightly newer one would open later. I'd close that too. Meanwhile the app stayed on a version with known issues. The alerts were doing their job. I wasn't doing mine.
The other surprise was everything Dependabot doesn't open a PR for. A lot of the leftover problems weren't even in my package.json. They were transitive, buried in the lockfile. No tidy bot PR. If you only merge what shows up in the inbox, you can look current and still be a few layers of node_modules behind.
A small config is the part that actually matters
What changed things was boring: a config that asked for weekly updates, a limit on how many PRs it opens at once, and a habit of reading those PRs instead of merging them in a stack.
A limit of five sounded reasonable until five lockfile PRs landed in the same hour. Merge one and the rest conflict. React would bump without react-dom. The Next.js ESLint package would jump ahead of Next itself. None of that is Dependabot being broken. It's Dependabot doing exactly what you asked, without knowing which packages have to move together.
So I stopped treating the queue as a list of merge buttons. I look at what it opened, group the ones that belong together, leave majors until I mean to take them, and keep paired packages in sync. I also keep the schedule in the repo so version updates don't depend on me remembering GitHub's settings page.
I'm still not merging everything blindly. Some updates are too big. Some need a real look. But Dependabot only helps if you tell it what "help" means, and then you actually follow through. Turning it on was the easy part. Configuring it—and using it—was the part I skipped.
Note: This is a mock-up post created as part of the Feather blog template demonstration. The content is provided as an example to showcase the blog's features including markdown rendering, search functionality, tags, and more.
Feather is a blog template built for Next.js. You can use these example posts as a reference when creating your own content.