Dependency Management Expertise
When This Applies
Apply this guidance when:
- Adding, updating, or removing project dependencies
- Resolving version conflicts between packages
- Auditing dependencies for security vulnerabilities
- Maintaining lock files
- Evaluating new dependencies
Evaluating New Dependencies
Before adding a dependency, check:
| Criteria | Check |
|---|---|
| Necessity | Can this be done in 20 lines of code instead? |
| Maintenance | Last commit < 6 months ago? Active maintainer? |
| Popularity | Downloads/stars indicate community trust |
| License | Compatible with project license? |
| Size | Reasonable bundle/install size? |
| Security | Known vulnerabilities? |
| Dependencies | How many transitive deps does it bring? |
Decision Framework
- Add it if: Well-maintained, widely used, saves significant work
- Skip it if: Unmaintained, huge dependency tree, simple to implement yourself
- Ask Architect if: Major new framework, changes the architecture
Version Management
Semantic Versioning
^1.2.3— Allow minor and patch updates (recommended for most deps)~1.2.3— Allow only patch updates (for stability-critical deps)1.2.3— Exact version (for known-fragile deps only)
Update Strategy
- Patch updates (1.2.x): Apply regularly, low risk
- Minor updates (1.x.0): Test thoroughly, check changelogs
- Major updates (x.0.0): Plan carefully, may have breaking changes — create a task for it
Lock File Management
- Always commit lock files (
package-lock.json,poetry.lock,Cargo.lock) - Never manually edit lock files
- Regenerate if corrupted: delete and reinstall
- Review lock file diffs in commits — large changes deserve scrutiny
Security Auditing
Run security audits regularly:
- npm:
npm audit - Python:
pip-auditorsafety check - Rust:
cargo audit - Go:
govulncheck
Vulnerability Response
| Severity | Action |
|---|---|
| Critical | Update immediately, create hotfix task |
| High | Update within current sprint |
| Medium | Schedule for next update cycle |
| Low | Track, update at convenience |
Dependency Conflicts
When two packages require incompatible versions:
- Check if either can be updated to resolve the conflict
- Check if an alternative package exists without the conflict
- If unavoidable, document the constraint and workaround
- Notify Architect if the conflict affects architecture decisions