A dependency budget is a cap on how many direct and transitive packages a shared library may pull in. Set it per library, check it in CI, and review it each year. Fewer packages means fewer advisories to triage and fewer surprises for every consumer.
Why a budget works
Every package is a future advisory, a future abandonment and a future breaking change. A shared library multiplies those costs across consumers. A budget turns "we should keep this lean" into something a pull request can fail on.
How to set the numbers
- Measure today: count direct and transitive packages for each shared library from its lockfile or SBOM.
- Pick a cap close to the current count for healthy libraries, and a lower target for bloated ones.
- Put the cap in the repository, such as a small config read by a CI script.
- Fail the build when a change pushes above the cap, with a message that says how to request an exception.
An example budget table
| Library type | Direct cap | Transitive cap | Notes |
|---|---|---|---|
| Small utility | 3 | 15 | Prefer none |
| Client for an internal API | 5 | 40 | HTTP client is the main cost |
| Authentication or crypto helper | 2 | 10 | Strict, two reviewers |
| Framework integration | 8 | 80 | Optional extras for the rest |
These numbers are placeholders. Use your own measurements.
Ways to stay under budget
Use the standard library where it is adequate. Replace a package used for one function with ten lines of code that you test. Split optional features into separate packages. Avoid packages that themselves have wide trees for narrow benefits.
Be careful with copying code. Vendored or copied code removes a package from the count but not from your responsibility. Record where it came from so you can track upstream fixes.
What the owner reviews yearly
- Packages that are deprecated or unmaintained.
- Packages that no code path uses any more.
- Packages that pulled in large transitive trees since the last review.
- Whether the cap itself still fits.
Show the trend
Report the counts per release in the changelog. A rising line prompts a conversation before it becomes a problem. Consumers like to see it too, since it predicts their own advisory load.
For intake rules on each addition see who approves a new dependency.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory to see how one component brings in others, and think about which you could drop.
Safeguard can help with the inventory side: its SBOM and dependency scanning shows which services pull in a given internal library, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Does a smaller tree mean a safer library?
Not automatically, but it reduces exposure to advisories and abandonment. Quality of the remaining packages still matters.
Should dev dependencies count toward the budget?
Track them separately with their own cap. They do not reach consumers but they can affect your build.
Last reviewed: 19 October 2026.
