Before adopting a library, view its full dependency graph, count the transitive packages it brings, and note who maintains them. Tools such as the deps.dev website show that graph without installing anything. If one small feature drags in dozens of packages, the real cost is larger than the library.
Why footprint is part of the decision
When you add a library you also add everything it depends on, and everything those depend on. Each package is another maintainer, another release pipeline and another source of advisories. You never chose them, but you ship them.
For the difference between the two kinds, see direct versus transitive dependencies and managing transitive dependencies.
Where to see the graph
Google's Open Source Insights service, at deps.dev, describes itself as examining each package and constructing a full, detailed graph of its dependencies and their properties. It indexes Cargo, Go, Maven, npm, NuGet, PyPI and RubyGems, and includes security advisories from OSV. The site lets you search for packages, visualize dependencies, compare versions and investigate advisories.
You can also inspect locally in a scratch directory:
npm install some-library --dry-run
npm ls --all
Use a throwaway folder so nothing lands in your project. Other ecosystems have equivalents, such as a resolver or tree command in the package manager.
What to record
| Question | Why |
|---|---|
| How many packages in total? | Rough size of the added surface |
| How deep is the tree? | Deeper trees are harder to update and audit |
| Any packages you already use? | Overlap reduces the added cost |
| Any with no recent releases or an archived repository? | Possible dead weight inside your build |
| Any that run install scripts or compile native code? | More execution at install time and more build requirements |
| Any with licenses you have not seen before? | License review applies to transitive code too |
Steps
- Open the library's page on deps.dev or run the dry-run in a scratch folder.
- Count total packages and note anything unusual.
- Compare with the in-house alternative. Our build or adopt guide helps.
- If the footprint is large for the feature you need, look for a smaller package, a standard library option, or a narrower import of the same library.
- Write the count in the pull request, so later growth is visible.
Footprints change over time
The graph you check today is a snapshot. A later release can add dependencies, and a dependency can change its own. Lockfiles hold a given resolution steady, but when you update, review the diff of the lockfile, not just the top-level version.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how many findings sit in code your application never calls, which is why a large footprint can create noise as well as risk.
Where Safeguard fits
Safeguard's SBOM and dependency scanning list direct and transitive components, and reachability analysis helps separate vulnerable code you call from code you merely ship. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is a bigger footprint always worse?
No. A well-maintained library with several well-known dependencies can be fine. The concern is surface you do not need.
Do devDependencies count?
They affect your build machines and CI rather than shipped code, but they still run on your systems. Include them in the review.
Sources
Last reviewed: 19 October 2026.
