The fix requires an intermediate library to raise its own constraint — how do you ship while that upstream pull request waits?

## Two tracks, deliberately separated When the blocker is a constraint inside a library you do not own, there are exactly two things worth doing, and confusing them is the classic mistake: - **The durable fix** changes the intermediate's constraint upstream, so the block disappears for you and for everyone else behind it. - **The shipping fix** changes only your build, right now, so your release is not blocked by someone else's review queue. A candidate who only does the first is blocked for weeks. A candidate who only does the second accumulates private divergence forever. The senior answer runs both, with the first defined as the thing that *deletes* the second. ## Making the upstream pull request easy to merge Maintainer latency is real, unpaid, and outside your control. What you control is how expensive your pull request is to review: - **Smallest possible diff.** Raise the constraint on the one dependency the advisory names. Do not bundle a lint fix, a formatting pass, or an upgrade of the whole dependency set — every extra hunk is another reason for a busy maintainer to defer it. - **Cite the advisory and the exact fixed version.** "Bump to allow `>=2.4.2`, which is the first release carrying the fix for this advisory" tells the maintainer *why* in one line and gives them the justification they need for their own release notes. - **Widen rather than pin, if the project's convention allows it.** A change from an exact pin to a range that includes the fix helps every consumer, including future ones; re-pinning to a new exact version just relocates the problem. - **Include or extend tests** if the change is more than a metadata edit, and confirm the project's own test suite passes against the newer version — that is the maintainer's actual concern, and answering it before they ask removes the main reason to stall. - **Route it correctly.** If the project publishes a security policy or a security contact, use it. A constraint bump that unblocks downstream vulnerability remediation is a different category from a routine dependency pull request, and maintainers often triage it that way. A public escalation thread rarely speeds things up and frequently costs you the maintainer's goodwill on the next one. - **Offer to carry it.** Volunteering to keep the change current against the project's main branch, or to help with the release, is often what converts "eventually" into "this week." ## Shipping in the meantime The local override needs to be sound rather than merely green. Two questions decide how much work it deserves: **How big is the delta?** If the fixed release is a patch above what the intermediate declares, the risk is close to zero: the whole point of a patch release is that the interface did not move. If it crosses a major version, you are forcing the intermediate to run against a library whose interface may have changed underneath it — the removed function, the changed signature, the renamed field. That breakage will not appear at build time in every ecosystem, and it can hide until a rarely executed path runs in production. **Which parts of the changed surface does the intermediate actually use?** This is the question that turns a guess into an assessment. Read the intermediate's usage of the library, compare it to the changelog between the two versions, and concentrate your testing there. A forced version in a compiled ecosystem where the resolver replaces one module with another will happily build and then fail at the exact call site the intermediate relies on. Integration tests that exercise the intermediate through its own public surface — not just your code — are what catch this. ## Governing the workaround Every override gets three attributes or it is not finished: 1. **An owner** — a named person or team, not "platform." 2. **A removal trigger** — the upstream release that makes it unnecessary, tracked so the check is mechanical. 3. **A test that fails if it stops applying** — an assertion on the resolved version, so a later graph change cannot silently revert you to the vulnerable one. And there is a decision point, not just a waiting room. If the upstream project is unresponsive for a period you have defined in advance — weeks, not days, and stated up front rather than rationalised afterwards — that is a signal about the dependency itself, and the conversation escalates from "how do we patch this" to "should we depend on this at all." Deciding that threshold before you are under pressure is what stops a temporary override from becoming a five-year-old line nobody dares to touch.