Not always, but fewer is better. Every dependency in your SDK is inherited by every customer, along with its vulnerabilities and maintainers. Aim for as few as you can justify, avoid pulling a package for a one line helper, and never write your own security primitives just to avoid a dependency.
What a dependency costs your customers
When a customer installs your SDK they install your whole dependency tree. A vulnerability in a package three levels down appears in their scanner, in their audit report and in their questionnaire answers, and they will open a ticket with you, not with the package author. The npm documentation notes that dependency graphs have grown much larger over the years, which is why tools now hide transitive packages unless asked.
You also inherit conflicts. If your SDK pins a strict version range of a popular package, you can block customers from upgrading it to get a fix.
A decision guide
| Situation | Suggested choice |
|---|---|
| Small helper, a few lines | Write it yourself and test it |
| HTTP client | Use the platform standard library or one well maintained client |
| Cryptography, TLS, parsing untrusted formats | Use a vetted library, never your own |
| Large optional feature (for example a specific serializer) | Make it an optional extra or optional peer dependency |
| Host framework your SDK plugs into | Declare it as a peer dependency |
| Code you must freeze for reproducibility | Bundle and record it |
The last row has a cost. Bundled code is invisible to many scanners and you become responsible for patching it, as the library patching posts discuss.
Peer and optional dependencies, defined
In npm, a peer dependency declares compatibility with a host package without requiring it directly, which suits plugins. Since npm 7, peer dependencies are installed by default, and a peerDependenciesMeta entry can mark one as optional so it is not installed automatically. The package manifest also supports bundleDependencies for packages included in the published tarball. Other ecosystems have equivalents, often called extras or optional features.
Steps to trim your SDK's dependencies
- List the full tree, not just direct dependencies. In npm that means asking for all levels, because the default shows only the top level.
- For each package, write down why it is there and what you use from it.
- Remove any package where you use one function that you could write and test in under an hour.
- Move rarely used features behind optional extras so most customers do not install them.
- Replace unmaintained packages. A package with no releases and open advisories is a liability you are forwarding.
- Loosen overly strict version pins so customers can take security fixes, and test against the oldest and newest supported ranges.
- Re-run the inventory on every release and compare it with the last one, so growth is a decision, not an accident.
Zero is a goal, not a rule
A dependency free SDK is attractive, but if reaching zero means copying a parser or a crypto routine into your tree, you have traded a visible risk for a hidden one. The measure that matters is how many packages your customers must trust and keep patched.
Try it yourself
Open the demo to see what a dependency inventory looks like, and look for how many transitive packages sit under each direct one.
Click through it at your own pace, or open it full screen.
Quick check
Is bundling a dependency safer than declaring it?
It removes version conflicts but makes patching your job, and many scanners cannot see bundled code. Bundle deliberately and record what you bundled.
When is a peer dependency the right choice?
When your SDK is a plugin for a host library and must share the host's single copy, rather than install its own.
Safeguard's SBOM and dependency scanning lists direct and transitive packages and its reachability analysis helps separate the advisories that matter from the rest. Try the free scan.
Sources
Last reviewed: 19 October 2026.
