Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From rampstack-skills
Manages third-party libraries, runtimes, and SaaS dependencies across package managers. Use when setting update cadences, responding to security advisories, evaluating new dependencies, or unblocking upgrades.
npx claudepluginhub rampstackco/claude-skills --plugin rampstack-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/rampstack-skills:dependency-managementThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Decide what to depend on, keep dependencies current, respond to advisories, and reduce supply chain risk. Stack-agnostic principles; specifics vary by package manager.
Audits project dependencies globally: inventories direct/transitive deps with tools like npm/pip/cargo audit, evaluates risks via matrix, plans actions (update/replace/eliminate), sets update policies.
Audits and hardens third-party dependencies with npm audit, lockfiles, Dependabot, script blocking, and vulnerability monitoring. Useful for CI security gating and supply chain hardening.
Audits project dependencies for bloat, unused packages, security risks, supply-chain issues, and upgrades by building import graphs and verifying call sites in npm, pip, Cargo, Go, Ruby projects.
Share bugs, ideas, or general feedback.
Decide what to depend on, keep dependencies current, respond to advisories, and reduce supply chain risk. Stack-agnostic principles; specifics vary by package manager.
code-review-web)security-baseline)vendor-evaluation)performance-optimization)Every dependency falls into one of these. The category drives the policy.
Code that runs in production and would break the system if it failed.
Examples: framework, database driver, payment SDK, authentication library.
Policy:
Code that runs in production but is replaceable or non-critical.
Examples: utility libraries, formatting, non-core integrations.
Policy:
^1.2.3)Code that runs only during development or build, not in production.
Examples: bundlers, linters, test frameworks, type checkers.
Policy:
Tools individual developers use that aren't part of shared dev environment.
Not really managed at the project level. Mentioned for completeness.
When evaluating a dependency, consider:
A dependency abandoned a year ago is a liability waiting to surface.
A small dependency that pulls in 50 transitive packages has the surface area of all 50.
A dependency you can't replace is leverage you've granted to its maintainer.
Every dependency has a cost. Free packages aren't free.
Run a dependency listing:
# npm/yarn/pnpm
npm ls --all --json
# pip
pip list
# gem
bundle list
For each top-level dependency, categorize (critical / supporting / dev). For transitives, you generally don't manage individually unless one becomes a problem.
Run the security audit:
npm audit
yarn audit
pip-audit
bundle audit
For each finding:
| Severity | Direct dep | Indirect dep |
|---|---|---|
| Critical | Patch today | Patch this week (if a fix exists; track if not) |
| High | Patch this week | Patch this month |
| Medium | Patch this month | Track; patch with next round |
| Low | Track | Track |
Critical and high in production code are emergencies. Low and medium are scheduled work.
Even patch-level updates can break things. For critical dependencies:
For supporting and dev:
Major versions break things. Plan rather than rush.
For each major upgrade:
Don't sit on major versions indefinitely. The longer you wait, the more painful the upgrade.
Document:
The policy is what survives team turnover. Without it, dependency management becomes chaotic ad hoc work.
Automation reduces toil. Manual checking doesn't scale.
Quarterly:
depcheck)Remove what's not used. Replace what's unmaintained.
Before adding a new dependency, answer:
Default: don't add. Add only when the value clearly exceeds the cost. The cost includes ongoing maintenance, not just installation.
When removing a dependency:
Removed dependencies sometimes leave config files, CI hooks, or imports behind. Search broadly.
No update cadence. Dependencies drift. When you finally upgrade, it's painful. Set a cadence.
Audit disabled in CI. "Too noisy." Tune the audit, don't disable it. Whitelist known false positives explicitly.
Pinning everything to exact versions. Stops automatic patches. Misses security fixes. Use narrow ranges with a lockfile.
Unpinned floating versions. latest in production. Builds aren't reproducible. Lockfile required.
Adding dependencies without review. "I just needed a quick utility." Now there are 50 unused dependencies. Require review for new dependencies.
Ignoring transitive dependencies. A direct dependency pulls in 50 indirect ones. Each is supply chain surface. Audit the tree, not just the top level.
Patching with major version bumps. "Updating to fix a bug" but the update is a major version. Now you have unrelated breaking changes too. Be deliberate about the version of the fix.
Vendor-bundled libraries. Some dependencies vendor copies of other dependencies. They're not visible to the audit. Periodically check.
Build-time dependencies treated as zero-risk. Build tools have access to your code and credentials. Supply chain attacks target them. Treat with appropriate care.
Fork without rebase plan. Forking a dependency to fix something. Then you own it. Plan how to rebase or merge upstream changes, or commit to maintaining the fork.
No license audit. Project ships with a GPL dependency in a commercial product. Compliance issue. Audit licenses on add and quarterly.
Update PRs piling up. Dependabot PRs go unmerged for months. Either tune to fewer PRs or commit time to merging them.
A dependency policy document includes:
references/upgrade-checklist.md: Step-by-step checklist for performing a major version upgrade of a critical dependency, from changelog reading to staged rollout.