Generate list of blocking upstream dependencies?

[jywarren]

I'm trying to update past a critical severity alert, but got the message Dependabot cannot create a pull request as one or more other dependencies require a version that is incompatible with this update.

That makes sense, and I can look through yarn.lock to see what dependencies must be updated to allow dependabot to create the PR, but it's laborious and error-prone to do this manually. I was wondering if there could be a feature to somehow list out which dependencies are blocking the critical severity one, and offer to open PRs for those too, to make a kind of tree of pre-dependencies (for lack of a better term). This could fast-track a course of action which addresses critical severity alerts.

Right now, we have a lot of dependabot PRs which we work through as we're able to, but we're not aware of if we're making progress towards the critical severity ones.

Thanks, we ❤️ dependabot!

[codingthat]

I would love a fix for this. Recently encountered this on a default project generated for the popular Express framework: expressjs/generator#258 I'm sure Dependabot knows what the conflict is...it'd be super helpful to have it share the details! :)

[jeffwidman]

We shipped a lot of improvements for this behavior with the NPM ecosystem:

• https://github.blog/changelog/2022-09-07-dependabot-unlocks-transitive-dependencies-for-npm-projects/
• https://github.blog/2023-01-19-unlocking-security-updates-for-transitive-dependencies-with-npm/

It's not a complete fix, but it addresses many of the scenarios that resulted in blocked updates.

While this issue makes sense in theory, it's not very actionable. It doesn't specify which ecosystem... much of this unlocking logic is custom per-ecosystem, so we need to know where it's being hit. And generally Dependabot doesn't know what is blocking--if it did, it'd include it in the PR. Instead, what may be happening is we may get a log message that Dependabot hasn't been taught how to parse, so it's simply treating it as a wall of text that we expose in the job logs.

So I'm going to close this, and if you do hit this in specific situations, please file a new bug and include more specifics so we can figure out the actual blocking bug for that particular scenario.