The last commit was 14 months ago. There are 47 open issues, the most recent responded to by a stale-bot auto-closer. The contributor graph shows one person — the original author — with the last activity in the same month as the last commit. The package has 4.2 million weekly npm downloads.
This is the profile of an abandoned package. It's in your transitive dependency tree right now, and you probably don't know it's there.
You'll find out when a CVE lands and the security advisory says "no patch available from the original maintainer." At that point you have hours, not weeks, to migrate off it — and the migration work that should have been planned as routine tech debt becomes an incident with on-call engineers debugging at 11pm.
Why "last commit date" misleads more than it reveals
Engineers commonly use last commit date as a proxy for package health. It's easy to check, it's in every repository view, and the intuition seems sound — active packages get updated. The problem is that it's both easy to fake and easy to misread.
Some packages are intentionally stable. A well-designed utility library that parses a fixed-format date string into a struct doesn't need commits every month. The code is correct, the API surface is small, and the maintainer isn't ignoring it — there's genuinely nothing to change. That package might show a "last commit" 18 months ago and carry essentially zero abandonment risk.
Other packages show high commit activity driven entirely by bots. Dependabot and Renovate automatically open and merge PRs to keep the package's own dependencies current. A repository with 200 bot-merged dependency bumps over the past year looks highly active in the commit graph. The actual maintainer may not have written a line of new code in two years — they've just left the auto-merge bot enabled. If a CVE lands in the package's own logic, there is no human in the loop to respond.
Last commit date is one data point. Treating it as a health score leads to false confidence on bot-maintained packages and false alarm on intentionally stable ones.
The signals that actually predict abandonment trajectory
Identifying packages at genuine risk requires looking at several factors in combination, not any single metric:
Issue response time trend
The most predictive single signal isn't whether issues get resolved — it's whether they get responded to. A maintainer who responds to new issues within 48 hours, even to say "this is working as designed, closing," is demonstrably engaged. A maintainer whose mean first-response time has trended from 3 days to 30 days to "no response on any open issue in the last 6 months" is showing the trajectory of abandonment before it's complete — often 6 to 12 months before they formally step away.
The trend over time matters more than the current snapshot. A package with a steady 30-day mean response time is a different risk profile from one where the mean has doubled in each of the last four quarters.
Bus factor
Bus factor — the number of contributors whose simultaneous loss would incapacitate the project — is the structural risk indicator. For a one-person project, the bus factor is 1 by definition. When that person takes a new job, burns out, or simply loses interest, the package is effectively abandoned with no transition path.
The npm ecosystem has a well-documented pattern of widely-used packages maintained by a single author. Many foundational utilities in common use trace their entire maintenance history to one person. When that person walks away, the package doesn't disappear from anyone's node_modules — it just stops receiving security patches, compatibility updates, or responses to the issues piling up in the queue.
Download trajectory
Is the broader community moving away from this package? A declining weekly download curve — especially one that correlates with a competing package growing — often leads formal abandonment announcements by 12 to 18 months. Developers who track the ecosystem migrate first. The teams that find out last are the ones who weren't watching their dependency graph and assumed that millions of weekly downloads meant long-term safety.
Open issue accumulation rate
Compute the ratio of open issues to total issues and track it over time, not just the current snapshot. A healthy package has a ratio that stays roughly stable — new issues open and issues close at comparable rates. An abandonment trajectory is visible as open count growing monotonically while the close rate approaches zero. When the stale-bot is the only thing closing issues, the ratio deteriorates fast.
Translating signals into a health score
These four factors — issue response time trend, bus factor, download trajectory, and open issue accumulation rate — can be combined into a 0–100 score that makes comparison and alerting tractable at scale.
A score in the 80–100 range: actively maintained, responsive to issues, multiple real contributors, growing or stable adoption. Sub-20: effectively abandoned by at least three of the four signals. The 20–60 range is where judgment and context matter most.
A score of 45 on a date formatting utility used in two non-critical places in your codebase is a low-priority planning item. A score of 45 on a package that validates JWT signatures, parses user-supplied input, or handles outbound HTTP requests in your core API is worth immediate attention — the blast radius of a CVE in a security-adjacent package with no active maintainer is disproportionate to the package's apparent footprint.
The score is a signal, not a verdict. It routes attention to the packages that warrant manual review, not the ones that don't.
What to do when you find an at-risk package
Security-adjacent packages: treat as blocking technical debt
Any package that handles authentication, authorization, input parsing, cryptography, or network communication with a health score below 30 should be prioritized above most other tech debt. The window between "package abandoned" and "CVE with no available patch" is often short and unpredictable. Migration planned over two weeks is qualitatively different from migration forced overnight by an active exploit.
Non-security packages: plan and schedule with a deadline
A logging wrapper, a string formatter, an assertion library — these are planning items, not emergencies. Find the maintained fork or actively maintained alternative, assess migration effort, schedule it like any other tech debt with a due date. The goal is to complete the migration before a CVE forces your hand. "Before a CVE" is not a specific date, which is exactly why it needs to be scheduled against a concrete deadline rather than left as backlog debt.
Finding the canonical successor
For many abandoned packages, an actively maintained fork already exists and the community has identified it. The canonical successor typically has the highest star count among forks, appears in the "is there a maintained fork?" issue threads on the original repository, and shows a download curve that has been growing while the original's has been declining. A GitHub fork search sorted by recent activity, combined with checking the original repository's pinned issues, usually surfaces the answer within 15 minutes.
Monitoring at scale
The challenge for teams managing 200+ packages in their dependency graph is that none of this analysis is feasible manually on any recurring basis. You can't audit the contributor graph and issue response trends for every package before every PR merge. The only viable approach is to score every package in the graph automatically, alert when a score drops below your defined threshold, and route that alert to the PR that introduced the package — or to the on-call channel when an existing package crosses the threshold without a code change being the trigger.
The ongoing monitoring cost is low. The alternative — discovering that a package you've depended on for three years is abandoned when a CVE drops with no patch — is not.
Depswright scores every package in your graph for maintainer health, and alerts you when a score drops below your threshold. Start free.
