Have security alerts about yarn.lock find the root cause/solution

[codingthat]

Hey everyone, I hope you're well. In the case I ran into today, I think this idea would be make for a much better flow with Dependabot. :)

My situation:

1. Dependabot generated security alerts about two libraries based on my project's yarn.lock.
2. I think* its automatic fix would either modify yarn.lock or add its recommended sub-sub-dependency version bump to package.json. The former doesn't seem appropriate and the latter may not be enough for an automatic fix to succeed—for example, if more than one sub-dependency needs to simultaneously be upgraded due to compatibility issues, not just the one Dependabot is singling out.
3. Therefore the best (sometimes only) solution would be to version-bump the highest-level dependency of the current project that would bring with it a version bump that would solve what's being complained about.

* I can't directly verify this comment from @hmarr, because in my use case there's an unrelated problem where Dependabot can't automatically fix due to some unspecified conflict, but when Dependabot found something it didn't like in yarn.lock that was not directly mentioned in package.json, the suggested fix did seem to be directly to yarn.lock given the example format it displays:

Translated into specifics:

1. clean-css, a sub-dependency of pug, needed a bump (ignore acorn for the moment, since that doesn't currently have any resolution that I know of, and Dependabot doesn't currently make it clear what the compatibility conflict might be.)
2. The automatic fix regarding clean-css, whatever it would be, cannot be done due to some unspecified compatibility conflict.
3. The solution in this case is to bump the pug dependency in package.json, because that resolves the clean-css bump in a way that's free from compatibility conflict. It would be great if this is what Dependabot figured out, reported, and suggested.

(In the case that it can't resolve the conflict automatically, it would be great to divulge the conflict it's discovered, which is what #1340 is about. In this case, that would help narrow down what needs to be done by pug to successfully bump acorn. With the above implemented, once such a bump were successful in pug and a new version released with it, Dependabot running on my project would find the new version of pug and suggest bumping it, instead of delivering a conflict report.)

[jeffwidman]

👋 Sorry for the glacially slow response here.

We've shipped a lot of fixes since this was originally filed including (among others): #1340 (comment)

Is this still happening regularly? If not, we should probably close and then re-open when there's a new specific example of broken behavior that we can tackle...

As mentioned in my other comment linked to ☝️ , while this issue makes sense in theory, it's not very actionable because if Dependabot knew what the root cause/solution was, then it will generally try to fix it... so this is a general symptom of more specific bugs depending on the specific scenario.