| license | Apache-2.0 |
| name | dependency-management |
| description | Managing third-party dependencies — version pinning, security auditing, license compliance, update workflows, lockfile management, supply chain security. Activate on "npm audit", "dependabot", "renovate", "pin versions", "dependency update", "supply chain", "license compliance", "lockfile", "security advisory", "typosquatting", "SBOM". NOT for internal monorepo package management (use monorepo-management) or publishing your own packages to npm/PyPI. |
| allowed-tools | Read,Write,Edit,Bash,Grep,Glob |
| metadata | {"category":"Code Quality & Testing","tags":["dependency","management","npm-audit","dependabot","renovate"],"pairs-with":[{"skill":"security-auditor","reason":"Dependency vulnerability scanning is a critical security audit dimension"},{"skill":"monorepo-management","reason":"Monorepo workspace dependency hoisting and version alignment require specialized management"},{"skill":"devops-automator","reason":"CI/CD pipelines automate dependency auditing, lockfile validation, and update workflows"}]} |
| category | DevOps & Infrastructure |
| tags | ["dependencies","package-management","npm","versioning","upgrades"] |
Dependency Management
Decision Points
1. Should I add this dependency?
Package evaluation flow:
├─ Code volume > 200 lines? → Proceed to evaluation
├─ Code volume 20-200 lines?
│ ├─ Pure logic (no edge cases, locale, timezone)? → Write yourself
│ └─ Complex domain (crypto, date handling, parsing)? → Proceed to evaluation
└─ Code volume < 20 lines? → Write yourself
Dependency evaluation checklist:
├─ Downloads/week?
│ ├─ < 10k → HIGH RISK (consider alternatives)
│ ├─ 10k-100k → MEDIUM (check maintenance)
│ └─ > 100k → Proceed
├─ Last commit within 2 years? → If no, find maintained fork
├─ License compatible with your project? → If GPL in proprietary, REJECT
├─ npm audit / Socket.dev clean? → If CVEs unfixed, REJECT
└─ Transitive deps < 50? → If > 50, reconsider blast radius
2. How to version pin?
By environment:
├─ Production app dependencies → Exact pins (1.2.3) + lockfile
├─ Library you publish → Tilde ranges (~1.2.3) for flexibility
├─ Dev tooling only → Caret (^1.2.3) acceptable for churn
└─ Never use star (*) → Catastrophic randomness
By risk tolerance:
├─ Zero-downtime services → Exact pins, staged rollouts
├─ Internal tools → Ranges OK with good test coverage
└─ Experimental projects → Ranges to catch breaking changes early
3. How to handle updates?
Automation decision:
├─ Team size > 3 developers? → Use Renovate or Dependabot
├─ High-churn project (>20 deps)? → Use automation with grouping
└─ Small/stable project? → Manual monthly audit acceptable
Tool selection:
├─ GitHub-only, simple needs → Dependabot
├─ Multi-platform or advanced grouping → Renovate
└─ Air-gapped environment → Manual with local scanning
Grouping strategy:
├─ Dev dependencies → Group all patch updates
├─ Production dependencies → One PR per major, group minors
└─ Security updates → Always individual PRs for visibility
4. How to respond to security advisory?
Severity triage:
├─ Critical (CVSS 9.0+) → Drop everything, fix within 24h
├─ High (7.0-8.9) → Fix within 1 week
├─ Medium (4.0-6.9) → Fix in next sprint
└─ Low (<4.0) → Fix opportunistically
Path analysis:
├─ Direct dependency → Update to patched version
├─ Transitive dependency?
│ ├─ Direct dep has update → Update direct dep
│ ├─ No update available → Use npm overrides/resolutions
│ └─ Dev dependency only → Assess if tooling reaches production
└─ No patch available → Find alternative or vendor/patch yourself
5. When to use npm overrides?
Use overrides when:
├─ Transitive dep has vulnerability, no upstream fix available
├─ Version conflict between multiple dependents
└─ Need to force newer version for compatibility
DON'T use overrides for:
├─ Working around peer dependency warnings (fix the root cause)
├─ Downgrading to avoid testing breaking changes
└─ Long-term fixes (pressure upstream to update)
