What the label actually switches off
Somebody archives a repository and the whole team panics. Let’s be precise about what happened, because it’s much narrower than people assume.
GitHub’s own docs list it plainly: issues, pull requests, code, labels, milestones, projects, wiki, releases, commits, tags, branches, reactions, code scanning alerts, comments and permissions all become read-only. You can’t open an issue. You can’t file a fix. What you still can do is clone it, fork it, star it, and read every line, and the maintainer can unarchive it tomorrow if they change their mind.
Here’s what archiving does not touch: the registry. Nothing about a read-only GitHub repo reaches npm. The tarball sits there, npm install resolves it, your CI goes green. That gap between the social signal and the distribution channel is where most of the confusion lives.
Want the number that makes this concrete? inflight lives in a repository literally renamed inflight-DEPRECATED-DO-NOT-USE, archived, last published in October 2016, carrying a deprecation notice that says it leaks memory and you should not use it. In the week ending 2026-08-29 it was downloaded 96,277,586 times.
Three kinds of archived, and only one is an emergency
Treating them as one category is how teams waste a sprint migrating off something harmless while the actual liability sits two levels down in the tree.
Archived and finished
Some code is done. That’s not a failure state, it’s the goal, and our whole industry is weirdly bad at admitting it. inherits shipped 2.0.4 in June 2019 and hasn’t needed a release since. It pulled 201,245,475 downloads in that same week. No deprecation notice, no open security advisory, roughly forty lines of prototype wiring that does one thing correctly. once is the same story: version 1.4.0, September 2016, 157 million weekly installs.
I’ll say the disagreeable part out loud. An archived dependency with zero known CVEs and a stable API is a safer bet than an actively maintained one going through its third rewrite, because the archived one cannot surprise you on a Tuesday. Churn is a risk too. We just don’t put it on dashboards.
Archived and rotting
Then there’s the other kind. Does the badge mean something different here? Completely. angular/angular.js is archived; the angular package still moved 857,610 copies that week. sass/node-sass is archived and deprecated with a blunt “no longer supported, please use sass”, last release 9.0.0 in May 2023, still 984,347 weekly installs. These have real attack surface, real native bindings, real dependency trees underneath them, and nobody upstream who can accept a patch.
Archived with a fork
The community moved and left a forwarding address. That’s the cheapest case to fix and the easiest to miss. faker is the sharpest example I know: after the January 2022 sabotage the original Marak/faker.js repository is gone entirely (the GitHub API returns a flat 404 for it today), yet the old faker package, stuck at the sabotaged 6.6.6 from 2022-01-05, still pulled 2,302,100 downloads last week. The successor @faker-js/faker shipped 10.6.0 on 2026-08-14 and did 18,555,741. Millions of installs a week are still pointing at a repository that does not exist.
Deprecated is a different word
Archiving is a GitHub gesture. Deprecation is a registry gesture. Same thing? Not remotely. They travel separately, and mixing them up produces bad triage.
request is deprecated on npm and its repo is not archived. It did 14,459,089 downloads last week, on a release from February 2020. har-validator, marked “no longer supported”, did 14,219,320. Meanwhile moment calls itself “a legacy project in maintenance mode” on its own docs page, isn’t archived at all, isn’t deprecated, and pulled 36,910,362. Three different failure shapes, three different responses.
Auditing your own lockfile
Start with what’s already installed. npm ls --all gives you the real tree, transitives included, which matters because almost every example above arrives as somebody else’s dependency rather than a line you wrote.
For each name, two cheap lookups. The registry document at registry.npmjs.org/<pkg> carries the deprecated field per version and the publish dates, so you can see the gap. The GitHub REST API returns an archived boolean straight from api.github.com/repos/<owner>/<repo>, no scraping needed. Open Source Insights at deps.dev exposes both through one API, plus an OpenSSF Scorecard; libraries.io covers other registries.
Dependabot keeps working through all of this, by the way. Its alerts fire from the GitHub Advisory Database matched against your dependency graph, not from upstream activity, so an archived project still triggers warnings. The catch sits on your side: GitHub does not scan archived repositories, so archiving your own service quietly ends its security alerts. That one bites people. I’ve watched a team archive an internal repo for tidiness and silently lose two years of alerting.
The decision, in order
Pin first. Lockfile exact, verified digest, done in ten minutes, and it buys you the time to decide properly instead of deciding at 2 a.m. Then check for a fork with real momentum, the @faker-js/faker pattern, which is usually a one-line change plus a test run. Vendor the code if it’s under about 200 lines and you understand it, since owning fifty lines beats depending on a ghost. Replace only when the surface is genuinely large, and budget honestly: a linter migration always costs more than the changelog implies.
Whatever you pick, wire it into the gate rather than a spreadsheet. My own CI ordering puts the dependency-state check early for exactly this reason: a check that runs on every push is the only kind that survives a busy quarter.
So what’s the actual verdict on that archived badge? It’s a date stamp. It tells you when a maintainer stopped answering, and nothing whatsoever about whether the code underneath still deserves your trust. Go look at the code.