Check five things before you run npm install: that the name is exactly right, how old the package and its latest version are, who maintains it, what scripts it defines, and whether its repository link matches its published contents. The npm view command shows most of this without installing anything.
1. Is the name exactly right?
Typosquats rely on a quick glance. Read the name letter by letter against the project's own documentation, and check the scope if there is one. If an AI assistant suggested the name, confirm it exists and is the one you meant. See slopsquatting.
2. How old is it, and how recent is the release?
A brand new package with a familiar sounding name is a warning. So is a long quiet package that suddenly shipped a new version. Print the publish times:
npm view some-package time
Note the version you are about to install and when it was published. A freshness delay can help here. See dependency cooldown periods.
3. Who maintains it?
npm view some-package maintainers
The npm documentation shows how to select fields; the same pattern works for any field in the package record, though you should verify field names against your npm version. Look for maintainer changes you cannot explain.
4. What scripts does it define?
npm view some-package scripts
An install, preinstall or postinstall entry deserves a read. See what an install script is.
5. Does the repository match?
npm view some-package repository.url dist.tarball
Open the repository. Does it exist, is it active, and does the code you see there resemble what is in the tarball? A repository that is unrelated to the package is a red flag, and attackers sometimes point to a real project's repository. Our post on GitHub repo confusion covers this trick.
If something looks wrong
Do not install it. Check the registry's reporting steps in how to report a malicious package, and choose an alternative.
Make it routine
Manual checks do not scale past a few new packages a week. For everything else, you want an inventory of what is installed and a gate that reviews changes to it.
Click through it at your own pace, or open it full screen. Look at how each package is listed with its version.
Quick check
Does a high download count prove a package is safe?
No. Counts can be inflated and popular packages can be compromised. Use them as one signal among several.
Do I need to read all the source?
No. For most packages, scripts, maintainers and a quick look at the entry file are enough to decide whether to go deeper.
Safeguard does SBOM and dependency scanning and policies and gates for pull requests. You can run a free scan on a project today.
Sources
Last reviewed: 19 October 2026.
