Which Packages Have the Most Open Issues? (And What It Means)
·PkgPulse Team
TL;DR
A package with 5,000 open issues can be healthier than one with 50 open issues — if those 5,000 are being triaged and resolved. Open issue count is the most misused metric in package evaluation. Next.js has 2,000+ open issues and is the most well-maintained full-stack framework. A side project with 8 open issues may have had no maintainer activity in 18 months. The signal is issue RESOLUTION RATE and RESPONSE TIME, not raw count.
Key Takeaways
- Issue count correlates with popularity — more users = more issues filed
- Resolution rate (issues closed / issues opened per month) is the real signal
- Next.js: 2,000+ open issues — but 1,500+ closed per month, full-time team
- P0 triage — how quickly are critical/security issues handled?
- "Stale" issues — well-run repos auto-close inactive issues; stale = normal
The Issue Count Trap
Comparing issue counts across packages is like comparing
number of support tickets across companies of different sizes.
Amazon has more support tickets than a small SaaS startup.
That doesn't mean Amazon has worse customer service.
Package size and popularity drives issue volume:
→ Next.js: 500M-page projects using it → millions of edge cases
→ Local side project: 5 users, 5 issues
Better questions to ask:
1. What percentage of issues filed this month were closed?
2. How quickly does a maintainer first respond to new issues?
3. Are CRITICAL issues (security, P0 bugs) addressed quickly?
4. Is the ratio of "closed issues" to "open issues" healthy?
High Issue Count, Well-Maintained Packages
Next.js — 2,000-3,000 Open Issues
# Why so many open issues:
# - Used by millions of developers
# - Complex product (bundler, router, rendering, edge runtime, etc.)
# - Teams expect framework-level support quality
# - Feature requests filed as issues (many are aspirational, not bugs)
# Why it's still well-maintained:
# - 1,500+ issues closed per month (larger than open backlog growth)
# - Vercel engineers triaging within 24-48h for critical issues
# - Labels: bug, enhancement, needs-investigation, stale
# - "Stale" bot closes inactive issues after 30 days
# - Security issues: private disclosure → patch in 24-72h
# Signal check:
# Open: 2,400 | Closed: 45,000 | Resolution rate: ~93%
# Average first response: < 48h
# Critical bugs fixed: within 1 week
# Assessment: Excellent maintenance despite large issue count
TypeScript — 5,000+ Open Issues
# TypeScript has one of the largest open issue backlogs in npm-adjacent packages
# Why:
# - Every TypeScript user is a potential bug reporter
# - Type inference edge cases are infinite
# - Feature requests accumulate (breaking changes require RFCs)
# - Microsoft teams move deliberately, not at startup speed
# But:
# - Critical bugs (type system correctness): patched in days
# - Response to confirmed bugs: typically 1-2 weeks
# - Feature requests: months to years (by design)
# - TypeScript team quality: exceptional
# Assessment: High issue count reflects ambition + scale, not poor maintenance
Low Issue Count, Problematic Packages
# A package with 5 open issues might have:
# ❌ Only 5 users (nobody filing issues)
# ❌ Maintainer who closes issues without fixing them
# ❌ No issue tracker (issues disabled or maintainer uses email)
# ❌ Auto-closing bot set too aggressively
# Signs of a problematic low-issue package:
# - Last issue opened was 8 months ago → nobody using it
# - Issue closed with "works for me" with no further investigation
# - No issue templates → high friction to file bugs
# - README says "please use email for issues"
# These are worse than packages with 2,000 active issues
# because at least active issue trackers show engagement
How to Evaluate Issue Tracker Quality
# GitHub issue tracker signals:
# ✅ Good signs:
# - Issues have labels: bug, enhancement, good-first-issue, stale
# - Maintainer responds within days on recent issues
# - Linked PRs on bug issues (fixes are coming)
# - Security issues closed quickly (or via private disclosure)
# - Regular "here's what we're working on" updates
# ⚠️ Concerning signs:
# - Newest issues have no response for 30+ days
# - P0 bugs sitting open for months
# - PRs opened and never reviewed
# - Many issues labeled "stale" with no resolution
# - "This project is looking for maintainers"
# ❌ Red flags:
# - Issues locked/disabled entirely
# - Critical security issues open for 6+ months
# - Repository archived with no migration path
# - Maintainer comments: "I don't use this anymore"
# Automation tip: GitHub's "is:open is:issue" + sort by "oldest"
# Shows the longest-sitting unresolved issues
# This is your best signal for what the maintainer won't address
Issue Resolution Rates for Popular Packages (Estimates)
Monthly issue metrics (approximate):
Open Closed Resolution % P0 Patch Time
Next.js: 2,400 1,500+ ~87% 1-7 days
React: 1,100 800 ~75% 3-14 days
Vue: 800 600 ~75% 1-7 days
Vite: 400 450 ~90% 1-3 days
Tailwind CSS: 600 500 ~85% 1-7 days
Fastify: 250 200 ~80% 1-3 days
Zustand: 120 130 ~90% 1-5 days
Prisma: 800 700 ~87% 3-7 days
Drizzle: 300 280 ~85% 3-7 days
Express: 500 100 ~40% ← maintenance mode: lower activity
Create React App: 80 5 ~5% ← deprecated, not resolving
The P0 Issue Test
# The most important signal: how are CRITICAL issues handled?
# What to search for on GitHub:
# is:open is:issue label:bug label:critical
# is:open is:issue label:P0
# is:open is:issue label:security
# or:
# is:closed is:issue label:security
# → Shows historical security response time
# The test:
# Find the most recent security issue filed
# Check: how long did it take to get a response? A fix? A release?
# If a package has:
# → Security issues patched in < 7 days: excellent
# → Security issues patched in 7-30 days: acceptable
# → Security issues open for 60+ days: concerning
# → Security issues open for 6+ months with no response: avoid
# Real example pattern:
# Popular auth package had CVE filed publicly (no private disclosure)
# Issue opened: Jan 1
# Maintainer first response: Jan 8 ("investigating")
# Fix PR: Jan 20
# Release with fix: Jan 22
# Total: 22 days — acceptable for the complexity of the fix
Using Issue Trackers in Your Dependency Evaluation
# Before adding a new dependency:
# 1. Open: github.com/org/repo/issues
# 2. Sort by: "Newest"
# → Do recent issues have responses? How fast?
# 3. Search: "security"
# → Are security issues closed? How quickly?
# 4. Check: "is:open sort:created-asc" (oldest open issues)
# → What old issues haven't been addressed?
# → If they're bugs that affect your use case: red flag
# 5. Search: "is:open label:bug"
# → How many open bugs? Are they minor or major?
# Quick health check via GitHub API:
curl -s "https://api.github.com/repos/pmndrs/zustand" | jq '{
open_issues: .open_issues_count,
forks: .forks_count,
last_push: .pushed_at
}'
# npm metadata also includes repository link:
npm view zustand --json | jq '.repository.url'
# Then navigate to GitHub and check the issues
Issue Quality vs Quantity
The type of open issues matters as much as the count:
Low-quality issues (don't indicate maintainer problems):
- Duplicate reports (users didn't search first)
- Support questions better suited for Stack Overflow
- Feature requests that don't align with project scope
- Issues from very old versions
- "Issues" that are actually user errors
High-quality signals (watch these):
- Reproducible bugs with no maintainer response
- Security vulnerabilities with no acknowledgment
- Regression issues ("this worked in version X")
- Issues with many upvotes (community agrees it's a real problem)
- Issues referencing production outages
The best-maintained packages have:
→ Issue templates that filter out noise
→ Auto-labeling for triaging
→ Clear scope statements ("we don't support X")
→ Friendly but firm closure of off-topic issues
→ Fast triage of legitimate bugs
A package closing issues is NOT a bad sign.
A package closing issues WITHOUT addressing the underlying bug IS.
Compare issue tracker activity and health scores for npm packages at PkgPulse.
See the live comparison
View next vs. remix on PkgPulse →