Yes. Removing an unused dependency is the cheapest upgrade you will ever do, because it ends every future update, advisory and review for that package. Run a pruning pass at the start of each quarter, before sizing the upgrade backlog, and the backlog gets smaller for free.
Why pruning comes first
Each dependency has a recurring cost: it can receive advisories, ship breaking changes, change maintainers, or go unmaintained. If a package is not used, you pay that cost for no benefit.
Google's chapter on dependency management makes a related point: dependencies are easy to add and costly to maintain over time, and the longer a package sits, the more other things come to depend on its particulars. Fewer dependencies means fewer of those entanglements.
Where unused dependencies come from
- A library tried in a prototype and never removed.
- A feature deleted, with its package left in the manifest.
- A tool moved from runtime to development use, but still listed as a runtime dependency.
- Two libraries doing the same job after a migration.
- Transitive packages pulled in by a library you stopped calling.
A quarterly pruning pass
- List direct dependencies. From each manifest, with the service that owns it.
- Check usage. Search the code for imports. Most ecosystems have a tool that reports declared but unused packages. Run it, then confirm by hand.
- Check indirect use. Some packages are loaded by configuration, plugins or build steps, with no import in your code. Look before deleting.
- Move, do not just delete. If a package is only needed for tests or builds, move it to the development group so it never ships.
- Remove in small pull requests. One or a few per change, so a break has a clear cause.
- Run the build and tests. Then a staging smoke test.
Decide, per candidate
| Finding | Action |
|---|---|
| Declared, never imported, no config reference | Remove |
| Used only in tests or build | Move to development dependencies |
| Used for one small function | Consider replacing with a few lines of your own code |
| Two packages doing the same job | Pick one, schedule the migration |
| Used, but unmaintained | Plan replacement, see abandoned open source project risks |
Be careful with the replace-with-your-own-code option. Writing your own cryptography, parsing or date handling often costs more than the dependency did.
Measure the effect
Record the number of direct dependencies and the number of total components before and after. Report the change in the retro, and note how many planned upgrades disappeared from the list. That is a concrete win for planning conversations.
Guard against re-growth
Add a lightweight rule to review: new dependencies need a one-line reason in the pull request description, and an owner. Some teams also check dependency footprint, as in checking a library's dependency footprint, before adopting anything new.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the split between direct and transitive components, and think about which direct ones you could delete.
Where Safeguard fits
Safeguard's SBOM and dependency scanning gives a full component list per repository and flags advisories, which helps you spot packages worth removing. A free scan is at gold.safeguard.sh/scan.
Quick check
Is it safe to delete anything a tool reports as unused?
Not blindly. Tools miss packages loaded through configuration or plugins. Confirm by search, then rely on tests and a staging check.
Does removing a package remove its advisories from my scan?
Yes, once the package is gone from every manifest and lockfile and the build is redeployed and rescanned.
Sources
Last reviewed: 19 October 2026.
