Dependency Management
Overview
Every dependency is a commitment -- to its maintenance, security surface, and upgrade path. Add deliberately, update strategically, audit regularly.
Core principle: Every dependency decision should be justified. Don't add what you can write. Don't ignore what you can update. Don't skip what you can audit.
When to Use
- Adding a new package or library to a project
- Security audit warnings (npm audit, pip-audit, cargo audit, etc.)
- Batch dependency update time
- Major version upgrade decisions
- Choosing between alternative libraries
- Lockfile merge conflicts
- Questioning if a package is still maintained
Don't use when:
- Internal module/code organization (that's refactoring)
- Learning a single package's API (that's research)
Decision Tree
digraph dependency_decision {
"What dependency decision?" [shape=diamond];
"Add new package" [shape=box];
"Update existing" [shape=box];
"Security alert" [shape=box];
"Remove package" [shape=box];
"Evaluation Criteria" [shape=box, style=filled, fillcolor=lightyellow];
"Update Type?" [shape=diamond];
"Urgency Matrix" [shape=box, style=filled, fillcolor=lightyellow];
"Usage check, remove" [shape=box];
"Patch" [shape=box];
"Minor" [shape=box];
"Major" [shape=box];
"What dependency decision?" -> "Add new package";
"What dependency decision?" -> "Update existing";
"What dependency decision?" -> "Security alert";
"What dependency decision?" -> "Remove package";
"Add new package" -> "Evaluation Criteria";
"Update existing" -> "Update Type?";
"Security alert" -> "Urgency Matrix";
"Remove package" -> "Usage check, remove";
"Update Type?" -> "Patch" [label="x.x.Z"];
"Update Type?" -> "Minor" [label="x.Y.0"];
"Update Type?" -> "Major" [label="X.0.0"];
}
New Package Evaluation
Before adding any dependency, evaluate against all seven criteria:
| Criterion |
Question |
Red Flag |
| Necessity |
Can stdlib or existing deps do this? |
Adding a package for 10 lines of code |
| Maintenance |
Last commit? Issue/PR response time? |
12+ months inactive, unanswered issues |
| Community |
Weekly downloads, stars, forks? |
Very low usage, single maintainer |
| License |
Compatible with project license? |
GPL in commercial project (license contamination) |
| Size |
Bundle size? Transitive dependency count? |
Massive dep tree for a small task |
| Security |
Known CVEs? Clean audit? |
Active security vulnerabilities |
| Alternatives |
Better/lighter alternative available? |
Picking the first result without evaluating |
Rule of thumb: If a package fails two or more criteria, find an alternative or write it yourself.
Update Strategy
| Update Type |
Strategy |
Risk |
| Patch (x.x.Z) |
Update immediately, run test suite |
Low |
| Minor (x.Y.0) |
Read changelog, update, test |
Medium |
| Major (X.0.0) |
Breaking change analysis, migration plan, test on separate branch |
High |
Workflow for batch updates:
- Update patch versions first, run tests, commit
- Update minor versions one by one, run tests after each
- Tackle major versions individually on feature branches
- Never batch major updates together -- isolate each one
Security Urgency Matrix
| Severity |
Exploit exists? |
Action |
Timeframe |
| Critical |
Yes |
Update immediately or apply workaround |
Hours |
| Critical |
No |
Priority update |
1-2 days |
| High |
-- |
Update within sprint |
1 week |
| Medium/Low |
-- |
Add to next update cycle |
Planned |
When a security audit reports vulnerabilities:
- Run the audit tool for your ecosystem (npm audit, pip-audit, cargo audit, bundler-audit)
- Classify each finding using the matrix above
- Address critical/exploitable issues before any other work
- Document accepted risks for findings you cannot immediately resolve
Lockfile & Pinning Rules
- Always commit lockfiles (package-lock.json, yarn.lock, poetry.lock, Cargo.lock, etc.)
- Pin exact versions for production dependencies where possible
- Use ranges only for libraries (not applications)
- Never manually edit lockfiles -- use package manager commands
- After resolving lockfile merge conflicts, always run install to regenerate
Common Mistakes
| Mistake |
Reality |
| "Popular package is safe" |
Popularity does not equal security. event-stream was hacked at 2M weekly downloads |
| "Lockfile commit is unnecessary" |
Without lockfile, builds are not reproducible |
| "Update everything at once" |
Batch updates make it impossible to isolate the source of issues |
| "Major update is just a version number" |
Breaking change = potential refactoring |
| "Dev dependency security doesn't matter" |
Supply chain attacks target build processes |
| "Add a package instead of writing 10 lines" |
Every package adds attack surface and maintenance burden |
Removing a Dependency
Before removing a package:
- Search the codebase for all imports and usages
- Check if other dependencies rely on it transitively
- Remove the import statements and package reference, then run the full test suite
- Verify the lockfile is cleanly regenerated after removal
Related Skills
- security-review -- For auditing vulnerable and outdated components (OWASP A06)
- systematic-debugging -- For diagnosing issues introduced by dependency updates
- verification-before-completion -- For confirming dependency changes do not break the build
1---2name: dependency-management3description: Use when adding new dependencies, deciding whether to update packages, running security audits on dependencies, evaluating library alternatives, or encountering outdated or vulnerable packages4---56# Dependency Management78## Overview910Every dependency is a commitment -- to its maintenance, security surface, and upgrade path. Add deliberately, update strategically, audit regularly.1112**Core principle:** Every dependency decision should be justified. Don't add what you can write. Don't ignore what you can update. Don't skip what you can audit.1314## When to Use1516- Adding a new package or library to a project17- Security audit warnings (npm audit, pip-audit, cargo audit, etc.)18- Batch dependency update time19- Major version upgrade decisions20- Choosing between alternative libraries21- Lockfile merge conflicts22- Questioning if a package is still maintained2324**Don't use when:**25- Internal module/code organization (that's refactoring)26- Learning a single package's API (that's research)2728## Decision Tree2930```dot31digraph dependency_decision {32 "What dependency decision?" [shape=diamond];33 "Add new package" [shape=box];34 "Update existing" [shape=box];35 "Security alert" [shape=box];36 "Remove package" [shape=box];3738 "Evaluation Criteria" [shape=box, style=filled, fillcolor=lightyellow];39 "Update Type?" [shape=diamond];40 "Urgency Matrix" [shape=box, style=filled, fillcolor=lightyellow];41 "Usage check, remove" [shape=box];4243 "Patch" [shape=box];44 "Minor" [shape=box];45 "Major" [shape=box];4647 "What dependency decision?" -> "Add new package";48 "What dependency decision?" -> "Update existing";49 "What dependency decision?" -> "Security alert";50 "What dependency decision?" -> "Remove package";5152 "Add new package" -> "Evaluation Criteria";53 "Update existing" -> "Update Type?";54 "Security alert" -> "Urgency Matrix";55 "Remove package" -> "Usage check, remove";5657 "Update Type?" -> "Patch" [label="x.x.Z"];58 "Update Type?" -> "Minor" [label="x.Y.0"];59 "Update Type?" -> "Major" [label="X.0.0"];60}61```6263## New Package Evaluation6465Before adding any dependency, evaluate against all seven criteria:6667| Criterion | Question | Red Flag |68|-----------|----------|----------|69| **Necessity** | Can stdlib or existing deps do this? | Adding a package for 10 lines of code |70| **Maintenance** | Last commit? Issue/PR response time? | 12+ months inactive, unanswered issues |71| **Community** | Weekly downloads, stars, forks? | Very low usage, single maintainer |72| **License** | Compatible with project license? | GPL in commercial project (license contamination) |73| **Size** | Bundle size? Transitive dependency count? | Massive dep tree for a small task |74| **Security** | Known CVEs? Clean audit? | Active security vulnerabilities |75| **Alternatives** | Better/lighter alternative available? | Picking the first result without evaluating |7677**Rule of thumb:** If a package fails two or more criteria, find an alternative or write it yourself.7879## Update Strategy8081| Update Type | Strategy | Risk |82|-------------|----------|------|83| **Patch** (x.x.Z) | Update immediately, run test suite | Low |84| **Minor** (x.Y.0) | Read changelog, update, test | Medium |85| **Major** (X.0.0) | Breaking change analysis, migration plan, test on separate branch | High |8687**Workflow for batch updates:**881. Update patch versions first, run tests, commit892. Update minor versions one by one, run tests after each903. Tackle major versions individually on feature branches914. Never batch major updates together -- isolate each one9293## Security Urgency Matrix9495| Severity | Exploit exists? | Action | Timeframe |96|----------|----------------|--------|-----------|97| Critical | Yes | Update immediately or apply workaround | Hours |98| Critical | No | Priority update | 1-2 days |99| High | -- | Update within sprint | 1 week |100| Medium/Low | -- | Add to next update cycle | Planned |101102**When a security audit reports vulnerabilities:**1031. Run the audit tool for your ecosystem (npm audit, pip-audit, cargo audit, bundler-audit)1042. Classify each finding using the matrix above1053. Address critical/exploitable issues before any other work1064. Document accepted risks for findings you cannot immediately resolve107108## Lockfile & Pinning Rules109110- Always commit lockfiles (package-lock.json, yarn.lock, poetry.lock, Cargo.lock, etc.)111- Pin exact versions for production dependencies where possible112- Use ranges only for libraries (not applications)113- Never manually edit lockfiles -- use package manager commands114- After resolving lockfile merge conflicts, always run install to regenerate115116## Common Mistakes117118| Mistake | Reality |119|---------|---------|120| "Popular package is safe" | Popularity does not equal security. `event-stream` was hacked at 2M weekly downloads |121| "Lockfile commit is unnecessary" | Without lockfile, builds are not reproducible |122| "Update everything at once" | Batch updates make it impossible to isolate the source of issues |123| "Major update is just a version number" | Breaking change = potential refactoring |124| "Dev dependency security doesn't matter" | Supply chain attacks target build processes |125| "Add a package instead of writing 10 lines" | Every package adds attack surface and maintenance burden |126127## Removing a Dependency128129Before removing a package:1301. Search the codebase for all imports and usages1312. Check if other dependencies rely on it transitively1323. Remove the import statements and package reference, then run the full test suite1334. Verify the lockfile is cleanly regenerated after removal134135## Related Skills136137- **security-review** -- For auditing vulnerable and outdated components (OWASP A06)138- **systematic-debugging** -- For diagnosing issues introduced by dependency updates139- **verification-before-completion** -- For confirming dependency changes do not break the build