How to Evaluate npm Package Health Before 2026

Why Package Evaluation Matters More Than It Used To

The npm registry contains over 2.5 million packages, and the average Node.js project installs hundreds of them — the vast majority of which the developer never directly chose. This scale creates a selection problem: how do you make good decisions about which packages to add, when there are often dozens of candidates for any given need?

The stakes have increased significantly since the supply chain attacks of 2022-2025. Malicious packages, compromised maintainer accounts, and abandoned packages with unpatched vulnerabilities are documented threats, not theoretical ones. A single poorly-chosen dependency can introduce a security vulnerability that affects your users, create legal risk through licensing conflicts, or create technical debt through maintenance obligations when the upstream project is abandoned.

At the same time, the tooling for evaluating package health has improved substantially. PkgPulse aggregates health signals from npm, GitHub, and bundlephobia into a single score. Socket.dev provides behavioral analysis that catches malicious packages before CVEs are issued. Bundlephobia shows gzipped bundle size and tree-shakeability before you install. These tools reduce the time required for a thorough health check from hours to minutes.

The two-minute health check described in this guide has been validated by the teams that use it: developers who follow this checklist consistently avoid dependency regret and choose packages that remain viable over a 1-3 year time horizon. The investment is small; the avoided cost is significant.

TL;DR

Before installing any package, run a 2-minute health check. Most dependency regrets come from skipping this step. Check: weekly downloads trend (not count), last release date, open issues vs closed ratio, bundle size, TypeScript support, and whether there's an actively maintained alternative. PkgPulse automates this with a composite health score — use it to compare before you commit.

Key Takeaways

• Downloads trend beats download count — is it growing or declining?
• Last release date matters for security — >12 months is a yellow flag
• Bundle size should match the problem size — a utility shouldn't be 200KB
• License check prevents legal issues — MIT/Apache-2 for commercial use
• Health score combines all signals — use PkgPulse before adding dependencies

The 2-Minute Health Check

These six checks take roughly two minutes in total and cover the most important signals for evaluating whether a package is worth adding to your project. None of them require installing the package first — they all run from public information in the npm registry, GitHub, and bundlephobia.

Check 1: Download Trend

# Go to npmtrends.com or pkgpulse.com/compare
# Search for your package vs its top competitor

# What to look for:
✅ Growing (week-over-week, month-over-month)
✅ Stable with high absolute numbers
⚠️  Flat for 12+ months → potentially stagnant
⚠️  Declining 20%+ year-over-year → developers moving away
❌ Cliff drop → major breaking issue or community exodus

# Example: date-fns vs moment.js
# moment.js: 14M/week but declining every quarter
# date-fns: 50M/week and growing
# The trend tells you which the community is choosing NOW

Download trend is more informative than download count because it tells you the direction the community is moving. A package at 10 million weekly downloads that's been declining 15% per quarter for two years is a different proposition from a package at 3 million downloads that's growing 20% per quarter. The former is a technology in decline; the latter is where the ecosystem is heading.

The trend data is the leading indicator that predicts what the download count will look like in 12 months. For long-lived projects, choose the packages the community is converging on, not the ones they're leaving.

Check 2: Last Release

# Check on npmjs.com (package page shows "x days ago")
# Or GitHub releases tab

✅ Released in last 3 months → actively maintained
✅ Released 3-12 months ago → healthy cadence
⚠️  Last release 12-24 months ago → investigate
❌ Last release 2+ years ago → likely abandoned (unless intentionally stable)

# Context matters:
# lodash: low release cadence is fine — it's a stable utility library
# A security library that hasn't released in 2 years? Red flag.

The last release date requires context to interpret. A stable utility library that hasn't changed in 18 months may be intentionally stable — ms (the time-string parser) last released in 2017 and works perfectly. A security library that hasn't released in 18 months is a red flag because security research is ongoing and patches should be expected. When evaluating last release date, ask: "what would I expect the release cadence to be for this type of package, and does the actual cadence meet that expectation?"

Check 3: Bundle Size

# bundlephobia.com — search any npm package

# What to look for:
✅ Size appropriate for functionality (utility = <5KB, UI library = <50KB)
✅ Tree-shakeable (only import what you use)
⚠️  Large library for simple task (100KB for date formatting = no)
❌ Not tree-shakeable + large = always pays the full cost

# Rule of thumb by category:
# Utility functions:   <5KB gzipped
# Validation library:  5-15KB gzipped
# State manager:       2-30KB gzipped
# UI component library: 10-100KB (but should be tree-shakeable)
# ORM:                 varies (Prisma is large but most is codegen)

Bundle size matters differently for different contexts. For browser-shipped JavaScript, every byte affects load time and parse time on mobile devices — a 100KB validation library is a meaningful performance cost. For Node.js server-side code, bundle size is less critical since it's not shipped to users, but it still affects install time, Docker image size, and the attack surface area. Zero dependencies at any environment is a positive signal for both security and reliability.

The tree-shakeability check matters for frontend code: a 50KB library that's fully tree-shakeable and you only use 5% of it contributes 2.5KB to your bundle. The same 50KB library with "sideEffects": false absent from its package.json always contributes 50KB. Check bundlephobia's "tree-shaken cost" entry to see the effective size.

Check 4: TypeScript Support

# Check package.json for "types" field
cat node_modules/your-package/package.json | grep '"types"'

# Or check npmjs.com — shows "DT" badge if uses DefinitelyTyped
# Shows "TS" badge if ships types natively (preferred)

✅ Ships native TypeScript types (package.json "types" field)
✅ @types/package actively maintained (check @types/* downloads)
⚠️  @types/ exists but is months behind the package
❌ No types at all → you'll be casting to `any` everywhere

Check 5: Open Issues + PR Health

# GitHub → Issues tab
# Look at: total open issues, issue age, maintainer responses

✅ Issues triaged within 2 weeks
✅ Open:Closed ratio below 1:3 (few open vs many closed)
✅ P0/security issues resolved promptly
⚠️  Issues sitting 60+ days with no response
❌ Known security vulnerabilities with no patch
❌ Maintainer's last response was "I'll look at this" 8 months ago

Issue response time is the most direct signal of maintainer engagement. A project where issues sit unresponded for 60+ days isn't necessarily abandoned — maintainers have jobs and other commitments — but the pattern reveals how the project handles its relationship with the broader community. Well-maintained projects develop triage systems: labeling incoming issues promptly, closing duplicates within days, routing feature requests separately from confirmed bugs, and acknowledging reports even when fixes aren't immediate. When you see hundreds of open issues with no labels and no maintainer comments, the absence of triage structure is itself the signal.

The security-specific sub-check deserves separate attention. Before installing a package in a security-sensitive context — authentication, cryptography, session management, file upload handling, SQL drivers — search the open issues for "CVE", "security", "vulnerability", or common attack-class terms. A security issue open for more than 30 days without any maintainer response is close to a disqualifying signal. Vulnerabilities in these contexts are actively exploited, and if the maintainers don't treat them urgently, you're accepting the responsibility of monitoring and patching manually — which most teams don't actually do. The practical rule: for security-critical packages, open security issues with no maintainer response is a hard stop; find an alternative.

Check 6: License

# Check SPDX license identifier
cat node_modules/your-package/package.json | grep '"license"'

# Common licenses for commercial use:
✅ MIT → can use, modify, distribute (most permissive)
✅ Apache-2.0 → similar to MIT, explicit patent grant
✅ BSD-2-Clause, BSD-3-Clause → permissive
⚠️  GPL-2.0/GPL-3.0 → copyleft: your code may need to be open source
⚠️  AGPL-3.0 → very strong copyleft (includes network use)
❌ BUSL-1.1 (Business Source License) → not open source for commercial use
❌ Proprietary → read the terms

# When in doubt: run `license-checker` in your project
npx license-checker --summary

License risk in commercial software concentrates in two common scenarios. The first is GPL or AGPL packages bundled into proprietary applications. GPL's copyleft requirement means any derivative work incorporating GPL code may need to be released under GPL terms. AGPL extends this further to cover network use — SaaS applications using AGPL-licensed code could theoretically be required to open-source their server-side code. The practical risk depends on how the package is integrated (linked versus bundled) and how actively the license terms are enforced, but for any commercially valuable application, using GPL or AGPL packages without legal review creates exposure that most teams aren't positioned to evaluate on their own.

The second scenario is packages using newer non-open-source licenses like BUSL (Business Source License). Several high-profile projects — including HashiCorp's Terraform and CockroachDB — relicensed away from open source in 2023-2024. BUSL packages are typically not licensed for commercial use until a specified conversion date. Using a BUSL-licensed package in production without reading its specific terms is a common oversight. Running npx license-checker --summary across your full dependency tree is the fastest way to get a dependency-wide view of every license your project carries — worth running before any significant production deployment.

TypeScript support quality varies more than the presence or absence of types. Native TypeScript support (types bundled in the package) means the types are authored alongside the code and stay in sync with releases. DefinitelyTyped (@types/*) types are community-maintained and sometimes lag behind the actual package API or have gaps. The best signal for TypeScript quality is trying to use the package in a TypeScript project and seeing whether the types are accurate, complete, and well-documented with JSDoc.

Interpreting the Signals Together

No single signal is decisive. A package with declining downloads but excellent maintenance (active maintainers, quick issue responses, recent security patches) might still be the right choice for your specific use case. A package with high downloads but zero issues in two years might be abandoned, or it might be simply mature and stable.

The health check is most valuable for identifying packages that score poorly on multiple dimensions simultaneously. A package with declining downloads, a last release 18 months ago, no TypeScript types, and 50 open issues with no maintainer responses has combined several yellow flags into a clear red flag — find an alternative. A package where one signal is concerning but the others are strong deserves investigation but not automatic rejection.

Using PkgPulse's composite health score accelerates this process. The score aggregates popularity, maintenance, community, and security signals into a single number that's comparable across packages. For comparing two candidates for the same job, the side-by-side view on PkgPulse shows all health signals at once, reducing the time to make a decision from five browser tabs to one.

The Full Checklist

## Pre-Install Checklist for: [package-name]

### Basics
- [ ] What problem does it solve? (define clearly before searching)
- [ ] Is there a simpler native alternative? (e.g., `fetch` vs axios for simple use cases)
- [ ] How many packages does it add? (`npm install --dry-run`)

### Health Signals
- [ ] Weekly downloads: _______  Trend: ⬆️/➡️/⬇️
- [ ] Last release: _______ (< 12 months = ✅)
- [ ] Bundle size: _______ gzipped  Tree-shakeable: Y/N
- [ ] TypeScript: Native / DefinitelyTyped / None
- [ ] Open issues: _______ vs Closed: _______
- [ ] License: _______ (MIT/Apache OK for commercial use)

### Security
- [ ] Known CVEs? `npm audit` after install
- [ ] Dependency tree depth (deep trees = more attack surface)
- [ ] Maintainer reputation (individual or org? active?)

### Alternatives Considered
- [ ] Compared to: _______
- [ ] Reason for choosing: _______

### Decision
- [ ] Install? Y/N
- [ ] Monitor via: PkgPulse / npm audit CI / Dependabot

When to Avoid a Package Entirely

Some patterns should make you look for alternatives before spending time on the detailed health check. Single-maintainer packages where the maintainer's last GitHub activity was more than 12 months ago are high risk. The math is simple: if the one person responsible for the package has stopped engaging, new CVEs and breaking changes from Node.js version updates won't be addressed.

Packages with "too many dependencies" relative to their purpose are a yellow flag. A simple string formatting utility with 15 transitive dependencies is a smell — each dependency is its own supply chain risk, and 15 dependencies for a utility suggests either code reuse that's not warranted or architectural choices that prioritized code sharing over correctness. Check the dependency tree with npm view package-name dependencies before installing.

Packages that recently transferred ownership — especially to an organization you haven't heard of — deserve extra scrutiny. The npm registry shows the publication history on each package's page. A package that was published by john-doe for 5 years and then suddenly published by enterprise-npm-solutions-llc is worth investigating before installing. This is a known vector for supply chain attacks where attackers acquire popular packages.

Very new packages (less than 6 months old) with very high download counts relative to their age deserve investigation. Legitimate packages achieve high downloads through organic adoption. Artificially inflated download counts via download bots have been used to make malicious packages appear more trustworthy in automated security scanners that use download count as a proxy for reliability.

Keeping Evaluations Current: Ongoing Monitoring

The initial health check is necessary but not sufficient for packages you've already installed. Packages change. A maintainer who was actively responding to issues in 2023 may have moved on by 2025. A package with no known CVEs today may have one disclosed tomorrow. Ongoing monitoring is the complement to the pre-install evaluation.

The practical approach for most teams is a combination of Dependabot (or Renovate) for automated patch updates, npm audit in CI for catching known CVEs in the current dependency tree, and a scheduled quarterly review of your most critical dependencies. The quarterly review doesn't need to be comprehensive — focus on the ten or fifteen packages your application depends on most directly and check whether any have changed their maintenance status, acquired new security advisories, or been superseded by better alternatives.

Socket.dev's GitHub Action adds ongoing protection for new dependency additions: any pull request that adds or updates packages triggers a behavioral analysis that flags suspicious changes. This catches the account-takeover and intentional sabotage attack vectors that pre-install checks and npm audit both miss.

The combination of a thorough pre-install evaluation and ongoing monitoring handles the full life cycle of dependency risk — selecting good packages initially and catching problems with existing packages before they become incidents.

Using PkgPulse Health Scores

PkgPulse health score dimensions:

1. Popularity (20%)
   → Download velocity, trend direction, GitHub stars

2. Maintenance (35%)
   → Release frequency, commit activity, issue response time
   → Most important dimension — predicts long-term viability

3. Community (25%)
   → Contributors, forks, StackOverflow questions, ecosystem articles

4. Security (20%)
   → Known CVEs, dependency vulnerability count, last security patch

Health score ranges:
90-100: Excellent — widely used, actively maintained, minimal risk
70-89:  Good — stable with room to improve
50-69:  Caution — investigate specific low-scoring dimensions
<50:    High risk — consider alternatives

Example use:
pkgpulse.com/compare/prisma-vs-drizzle
→ Shows health scores side-by-side
→ Shows download trends over 12 months
→ Shows bundle sizes, TypeScript support, license

The composite health score is most useful as a screening and comparison tool, not as the final word on a package. Use it to eliminate clearly high-risk packages early — anything under 50 should trigger an explicit decision about whether to proceed — and to compare two candidates for the same job side by side. When two packages score 87 versus 72, the interesting question is which dimension is pulling the lower score down. If it's the maintenance dimension (which carries 35% weight), that's worth understanding before committing. If the lower score is driven by community metrics and you're evaluating a package for a narrow, well-scoped problem with an active but small maintainer base, the lower community score may not matter for your specific use case.

Health scores also change over time, which creates an ongoing monitoring responsibility. A package that scored 85 when you first added it eighteen months ago may sit at 62 today because maintenance activity has declined, open issues have accumulated, or the GitHub repository has gone quiet. The quarterly dependency review mentioned in the monitoring section above should include pulling current health scores for your most critical packages and flagging any that have dropped significantly. A 15-point or greater drop is an early warning sign worth investigating — it often precedes the more public signals of a project losing momentum, and catching it early gives you time to plan a migration rather than reacting to an incident.

The most efficient workflow for teams adding health score evaluation to their process: treat it as a gate, not a retrospective. Require a health score check before any new dependency is approved — in code review, or in your team's explicit dependency review process. For new projects, this integrates naturally into architecture decisions. For existing projects, a one-time audit of health scores across your full dependency tree surfaces the highest-risk packages to prioritize. Most teams discover two or three packages in any significant project that score poorly enough to warrant either a planned replacement or active monitoring. Addressing these proactively is substantially cheaper than dealing with them under pressure after they become security incidents or unplanned breaking changes.

Search and compare npm package health at PkgPulse.

See also: Prisma vs Drizzle and How Health Scores Help You Choose Packages, npm Dependency Trees: Most Nested Packages 2026.