Before adding a dependency, ask four things: do I really need it, who maintains it, what else does it pull in, and how would I remove it. Ten minutes on those questions prevents most of the pain that arrives later, and none of it needs special tooling.
Do you need it?
Every dependency is code you did not write and will not review line by line. If the function takes twenty lines and you understand it, write it. If it is cryptography, date handling or parsing untrusted input, use a well tested library instead.
Who maintains it?
Look at the repository. Are issues answered? When was the last release? Is there more than one maintainer? A single maintainer is not a reason to reject a package, but it is a reason to plan an exit.
What does it pull in?
The package you chose is the visible part. Its own dependencies come along and so do theirs. Check the size of the tree before you commit to it.
npm install --dry-run some-package
npm ls --all
A tiny helper that drags in dozens of transitive packages is a poor trade.
Which kind of dependency is it?
In package.json, runtime needs go in dependencies and tooling used only during development goes in devDependencies. People who install your package do not receive its devDependencies. Putting a build tool in the wrong section either bloats what you ship or breaks it.
How would you remove it?
Wrap the library behind a small function of your own so calling code does not touch it directly. If the package is later abandoned or compromised, you change one file.
Record the decision
Write one line in the pull request: why this package, which version, who maintains it. Reviewers can then challenge the choice, and in a year you will remember the reason.
Then keep watching
Checks at the door do not cover what happens next. New vulnerabilities are published against old packages every week, so a dependency that was fine in March can be a problem in October. A dependency scan on every pull request and on a schedule closes that gap.
Quick check
Should I pin an exact version?
Pinning gives predictable builds, and a lockfile already records the exact tree. Exact pins in the manifest also mean you must update deliberately, so pair them with a regular update routine.
Is a dependency with one maintainer too risky?
Not automatically. It raises the cost of abandonment, so keep the library behind a thin wrapper and watch for release activity.
Sources
Last reviewed: 19 October 2026.
