npm Package Info & Size Checker

Before You Install: Five Numbers Worth Checking

Every npm install is a trust decision. You're pulling code authored by strangers, executing it in your build, shipping it to your users. Most packages are fine. Some aren't. The npm Package Info checker surfaces five quick signals that help you spot trouble before it lands in your node_modules.

Signal 1: Latest Version and Release Cadence

A package's version history tells you a lot.

• Many recent releases → actively maintained. The author is responsive to bugs and new ecosystem versions.
• Last release 3+ years ago → likely abandoned. Not automatically bad (some packages are "done"), but check the issue tracker for unanswered bug reports.
• Pre-1.0 (0.x.y versions) → semver doesn't apply formally. Breaking changes can ship in minor versions. Pin tightly.
• Frequent major bumps (3+ in a year) → unstable API. Upgrade cost will be high.

The version field shows you the latest. Cross-reference on npmjs.com for the full release timeline.

Signal 2: Weekly Downloads

Downloads are the closest thing to a popularity metric in the JS ecosystem.

Important caveats:

• Downloads ≠ users. CI builds re-download. A single CI server can drive 100k downloads/week for a small team.
• Downloads include indirect. If react depends on a small util, the util inherits all of React's downloads.
• Sudden spikes can mean a new framework adopted the package or a security alert prompted reinstalls.
• Drops mean obsolescence or a reputation event (security disclosure, license change, controversial maintainer action).

Use the trend, not just the snapshot.

Signal 3: Unpacked Size and File Count

The unpacked size is the total bytes on disk after npm install extracts the tarball. It is NOT:

• The download size (tarballs are gzipped; usually 3-5× smaller).
• The bundle size (tree-shaking removes unused code).
• The runtime memory footprint (only the imported code is parsed).

It IS:

• A rough indicator of "how much stuff is in this package."
• A hard floor on how much disk space the package will take in your node_modules (multiplied by every project that installs it).
• A warning sign if it's surprising, a "color name" package shouldn't be 5MB.

Cross-reference with Bundlephobia for actual bundle impact. The Bundlephobia number is what users will pay; the npm unpacked size is what your CI will pay.

File count matters too:

• < 10 files → focused package.
• 10-100 files → typical mid-size library.
• 1000+ files → something is wrong (probably shipped node_modules or test fixtures). The famous "left-pad with 800 files" pattern.

Signal 4: Dependency Count

The direct dependencies reveal a lot about the package's design philosophy.

A few common patterns:

• 0 deps. Pure utility. Author has resisted the urge to add deps for convenience. Often the safest choice.
• 1-5 deps. Targeted dependencies. Each one is probably essential.
• 5-20 deps. Real library with infrastructure. UI components, ORMs, build tools.
• 20+ deps. Either a framework (Next.js, Nuxt) or a red flag. Framework: expected. Else: check what they are.
• One dep per character of source code. The famous antipattern. Some packages exist solely to wrap a one-liner; transitively they pull in dozens of micropackages, each a separate supply-chain risk.

This tool shows direct deps. For transitive depth, install and run npm ls --all or use npm-remote-ls from a terminal.

Signal 5: Metadata Health

• Author / Maintainer. A well-known individual or organization is a positive signal. "Anonymous" or single-use accounts deserve a deeper look.
• License. MIT/Apache/BSD: safe for most projects. GPL: copyleft concerns (see our license-checker). Missing/UNLICENSED: legal gray zone.
• Repository. Should link to a real GitHub/GitLab/Codeberg URL. Missing repo = harder to audit.
• Homepage. Should exist and load. Dead links hint at abandoned packages.
• Description. Should describe what the package does, not "TODO" or be missing. Quality signal.

Red Flags to Watch For

• Typosquats. "reqwest" vs "request"; "@nope/utils" instead of "@nopejs/utils". A package one keystroke away from a popular one is often a malware lure. Always verify the exact spelling.
• Recent first publish + high downloads. A brand-new package with 1M downloads in week one is suspicious. Could be a legit corporate launch; could be CI farming or a hijack.
• Mismatched repository. Repo points to a fork that's been deleted, or the linked repo has nothing to do with the package. Hijack indicator.
• Postinstall scripts. Packages that run code at install time can do anything. Most legit packages don't have them. Check scripts.postinstall in the package's package.json before adding to a build that runs on a sensitive machine.
• Mass-modified by a new maintainer. a-package was published by Alice for 5 years; this week Bob pushed v2.0 with 50 file changes. Verify what changed.

The npm registry has had real supply-chain attacks: event-stream (2018, postinstall malware in a transitive dep), ua-parser-js (2021, account hijack), colors.js / faker.js (2022, maintainer self-sabotage). Reading metadata catches the most obvious ones.

When the Numbers Don't Tell the Whole Story

• An old, low-download package may be perfect for a niche need. Specialized tools have small user bases by definition.
• A high-download package can still be poorly maintained. Popularity is sticky; quality decay lags.
• A small, focused package can be far better than a popular bloated one. Always weigh "right tool for the job" vs "most popular tool for any job."

The numbers are inputs to a judgment call, not a verdict.

Privacy

Lookups go directly from your browser to the npm registry. We don't proxy or log them. Open DevTools Network during a check: you'll see two outbound calls, one to registry.npmjs.org for metadata, one to api.npmjs.org for download stats. Both are public APIs. Nothing else.