When one new direct dependency brings in a large number of transitive packages, find the parent in the dependency tree, ask whether the feature justifies the added surface, look for a lighter alternative, and decide before merging. Each transitive package is code you now ship and must keep patched.
Why the tree matters
You choose direct dependencies, but you inherit everything they depend on. Each inherited package has its own maintainers, release habits and vulnerabilities. A diff that lists many new components under one pull request is telling you the cost of that single choice. A review that only reads the direct line misses it.
GitHub's dependency review lists indirect dependencies for lock files, so the cost is visible at review time if you look.
Steps
- Generate the dependency tree for the branch and for the target.
- Identify which new direct dependency introduced each new transitive one.
- Count the new packages and note any that duplicate functionality you already have.
- Check for duplicates at several versions, which waste space and double the patching work.
- Look at maintainers and activity for the most exposed new packages.
- Decide, and record the reason in the pull request.
Options when the tree is too big
| Option | When it fits |
|---|---|
| Accept it | The feature is core and the packages are well maintained |
| Use a lighter library | A smaller option covers your actual use |
| Write the small part yourself | You need a tiny slice of a large package |
| Move it to development scope | It is only needed for tests or builds |
| Isolate it | Put it in a separate service so the exposure is contained |
| Reject | The cost clearly outweighs the benefit |
Writing code yourself is not automatically safer. Own code needs tests and review too. Choose it only when the slice is genuinely small.
Set a rule you can apply
Agree on a trigger, for example that any pull request adding more than a team chosen number of transitive packages needs an extra approver. Pick the number from your own repositories, after looking at what normal pull requests add. A fixed figure borrowed from another team will not fit your codebase.
Reachability and size
Many of the new packages may never be called by your code. Reachability analysis can show which vulnerabilities in them sit on live paths and which do not. That does not remove the maintenance cost, but it sharpens the urgency when advisories appear.
Keep watching after the merge
Large trees change often. Each update of the parent can move many children. Monitor the component continuously, and revisit the decision if it becomes a frequent source of alerts.
Safeguard scans dependencies and SBOMs, runs reachability analysis, and offers policies and gates for pull requests. Look at a project on the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Find how direct and indirect components are listed, and see which parent brings each one.
Quick check
Are transitive packages my responsibility?
Yes in practice. They ship in your product and need patching when advisories land.
Is a bigger tree always worse?
Not always, but it is more to maintain. Decide knowingly and record why.
Sources
Last reviewed: 19 October 2026.
