| 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 install or npm audit.
- Keep the fix surgical: update the dependency, refresh the lockfile, and verify the packaging path.
Examples
vscode-extension moved from @vscode/vsce ^3.7.1 to ^2.25.0 after Dependabot showed the 3.x line was stuck on @azure/msal-node -> uuid@^8.3.0; npm audit and npm run package both passed afterward.- 2026-04-26 revalidation: even after a repo-wide "upgrade to latest" sweep,
@vscode/vsce 3.9.1 still reopened the same vulnerable @azure/identity -> @azure/msal-node -> uuid chain. The correct move was to keep ^2.25.0, refresh the lockfile, and prove npm audit plus npm run package still 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 audit while skipping the real release/package command.
