Search for every use, remove it from the manifest, regenerate the lockfile, prune extraneous packages, and run the full test suite. Do it in a small pull request on its own. Removing a dependency shrinks what you must patch and watch, which is one of the cheapest security improvements available to a new developer.
Why removal counts
Every package is code you did not write and must keep current. Each one can carry advisories, install scripts and maintainer risk, plus its own transitive packages. A dependency that nothing uses still sits in your tree and in your scan results. Removing it shrinks all of that at once.
Step by step
- Search the code. Look for imports, requires and string references, including config files, build scripts, tests and dynamic loading. A name can appear in a plugin list without an import.
- Check tooling. Linters, test runners and bundlers often reference packages by name in config.
- Ask the owner. If it is in a shared library or a monorepo package, someone else may depend on it.
- Remove it with the package manager's uninstall command, so manifest and lockfile change together.
- Prune. The npm documentation says npm prune removes extraneous packages, and with a name argument removes only matching ones. Run it to clear leftovers from your working tree.
- Check the lockfile diff. Confirm the removed package and its exclusive transitive packages are gone and nothing unrelated moved.
- Test. Run unit tests, a production build and any smoke test.
- Ship it alone. A separate pull request makes any regression easy to trace.
Watch for traps
| Trap | What to do |
|---|---|
| Used only in a script | Search scripts and CI config |
| Peer dependency of another package | Check peer requirements before removing |
| Loaded dynamically by name | Search string references, not just imports |
| Shared by a sibling package | Check the whole workspace |
Prove the benefit
Compare the dependency count and scan results before and after, and mention them in the pull request. It makes the work visible and encourages more of it. Setting a dependency budget turns this into a habit.
When not to remove
If you are unsure and the package is deep in a framework, leave it and ask. A confident wrong removal is worse than a package that stays another week.
Where Safeguard fits
Safeguard can do the inventory and watching for you. Its SBOM and dependency scanning lists what a repository actually pulls in, reachability analysis helps separate reachable findings from noise, and policies can gate a pull request. You can try a free scan on a repository to see the output.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which findings are in code that is actually called, a useful clue when deciding what to remove first.
Quick check
Does removing a package from package.json delete it from node_modules?
Not always by hand. Use the uninstall command or run npm prune so the tree matches the manifest.
Can a scanner tell me a package is unused?
It can hint, for example through reachability, but confirm with a code search and tests.
Sources
Last reviewed: 19 October 2026.
