Measure the dependency footprint of an SDK by listing the full tree of direct and transitive packages for each release, then tracking the count, the depth, how many are unmaintained, and how many have known advisories. Compare each release with the last, and treat growth as a change that needs a reason.
Why measure at all
Customers inherit everything your SDK depends on. A footprint that creeps up by one package a release becomes a large attack surface in a few years, and nobody decided it. Measuring turns a vague worry into numbers you can review, the same way you track bundle size or test coverage.
Package managers can show you the tree. The npm documentation says its listing command prints installed package versions in a tree structure, includes transitive dependencies when the all flag is given, and by default shows only the immediate dependencies of the root project. So the first mistake to avoid is reading the default output and concluding the footprint is small.
Metrics worth tracking
| Metric | What it tells you |
|---|---|
| Direct dependency count | Decisions your team made |
| Total unique packages | What customers actually install |
| Maximum tree depth | How far trust extends |
| Packages with a known advisory | Immediate exposure |
| Packages with no release for a long period | Maintenance risk |
| Packages with install scripts | Code that runs at install time |
| Duplicate versions of the same package | Bloat and patching confusion |
| Optional versus required split | How much customers can avoid |
Steps to build the measurement
- Generate the full tree from a clean install in CI, using your ecosystem's tree command with the all option, or export a software bill of materials in a standard format.
- Save the output as a build artifact named for the release, so history is available.
- Compute the metrics above with a small script. Start with three: total unique packages, maximum depth, and packages with advisories.
- Diff against the previous release and print additions and removals in the pull request.
- Add a review rule. A new direct dependency needs a one line justification from the author, covering what it does, who maintains it and why a few lines of code would not do.
- Set a soft budget, for example a maximum number of packages for the core install, and treat crossing it as a discussion, not a fixed failure.
- Re-run the report on a schedule, not just at release, because advisories appear after you ship. Publish a fixed release when a reachable one lands in your tree.
- Share the numbers in your release notes. Customers like seeing that you watch this.
Reading the numbers
Total count matters more than direct count. Depth matters because each level is a maintainer you have never met. Advisories need context: a package with a known issue that your SDK never calls is lower urgency than one on the request path, which is why reachability information helps. For ways to cut the tree, see whether an SDK should have zero dependencies.
Try it yourself
Open the demo and look at how a dependency inventory lays out direct and transitive packages, then picture the same view for your SDK.
Click through it at your own pace, or open it full screen.
Quick check
Is a small direct dependency list enough?
No. One direct dependency can bring dozens of transitive ones. Count the whole tree.
How often should the report run?
On every pull request that touches dependencies, at every release, and on a schedule, since new advisories arrive after you publish.
Safeguard's SBOM and dependency scanning does this inventory, and reachability analysis shows which findings your code actually reaches. Try the free scan.
Sources
Last reviewed: 19 October 2026.
