By name: "dependabot-tooling-downgrade" description: "Use a validated tooling downgrade when Dependabot flags an unpatchable transitive vulnerability in build-only dependencies." domain: "dependency-management" confidence: "medium" source: "earned"
Context
Use this when a Dependabot or npm audit failure comes from a dev-only packaging/build tool and the current major line has no viable patched transitive path.
Patterns
- Confirm the failing dependency chain from the Dependabot or audit logs before changing anything.
- Check whether Dependabot's suggested replacement version actually removes the vulnerable transitive stack.
- Prefer a real dependency change over ignoring the alert when the downgraded tool still supports the repo's required workflow.
- Validate the exact release command after the change, not just
npm installornpm audit. - Keep the fix surgical: update the dependency, refresh the lockfile, and verify the packaging path.
Examples
vscode-extensionmoved from@vscode/vsce^3.7.1to^2.25.0after Dependabot showed the 3.x line was stuck on@azure/msal-node -> uuid@^8.3.0;npm auditandnpm run packageboth passed afterward.- 2026-04-26 revalidation: even after a repo-wide "upgrade to latest" sweep,
@vscode/vsce3.9.1still reopened the same vulnerable@azure/identity -> @azure/msal-node -> uuidchain. The correct move was to keep^2.25.0, refresh the lockfile, and provenpm auditplusnpm run packagestill passed.
Anti-Patterns
- Ignoring the alert before proving there is no workable package-level fix.
- Assuming the latest version is always the safest path.
- Validating only with
npm auditwhile skipping the real release/package command.