Denial: "These dependabot MRs aren't even fixing real security issues, these do not exist in the wild."

Bargaining: "Okay we'll fix them but we'll do it on a schedule, so that it doesn't interrupt sprints."

Anger: "Okay let's just yoink the package lock file how about that?"

Depression: [skip ci]

Acceptance: "So apparently copilot can do this..."

undefined

    At sufficient scale, Dependabot’s analysis will time out before completing, effectively rate-limiting the number of PRs it can generate. This natural throttling prevents notification fatigue while maintaining the appearance of active security tooling.

Am I being trolled?

   > Modern languages like Zig, Gleam, and Roc offer genuine productivity benefits and attract top talent. As a bonus, their ecosystems are young enough that security tooling has not caught up yet. Dependabot will add support eventually, but until then you get the best of both worlds: a modern stack and a quiet PR queue.

How the hell is that actually a good thing? You might as well just use another language and disable Dependabot security updates if that's what you're looking for. Dependabot security updates aren't a liability, they're an asset in a world where developers use hundreds of dependencies daily, where every few months one of them is going to have a XSS or RCE vulnerability that has to be patched ASAP.

   > And if you are really concerned about a dependency’s security, you can always rewrite it yourself in Rust over a weekend.

That's not how it works. Honestly, this blog post gets me really worried about this developer's projects and clients.

   > Remove lockfiles from version control

What the fuck.

Had fun reading this, pretty well written. >Consolidate into a monorepo lol this sounds like as if you make a dog tired by playing with it so it sleeps which you're gone :'D

>Contextualize the actual risk This is not as easy as it seems, for example reflection cases where runtime behavior affects a package usage. example: const lib = require(process.env.PARSER) lib.parse(userInput) could use a safe parser in production or a vulnerable one in another environment, but from a code level perspective there's no certainity which package is actually used

Excellent troll post. I've had a good chuckle.

seems the easiest way is to switch from Microslop GitHub to another platform