CSV Parser Maintenance Health, Read From the Registry

The companion page to CSV library downloads, 2026, which measures adoption. Adoption tells you what people already use. It does not tell you whether the thing you are about to depend on will still be maintained in two years, and for a parser — a component you replace roughly never — that second question matters more.

This page measures maintenance instead, straight from registry metadata. Every number is a field in the package document, so the whole table is reproducible in one command.

How this was pulled

node scripts/pull-registry-meta.mjs papaparse d3-dsv   # one line per package
curl -s https://registry.npmjs.org/papaparse           # the raw document behind it

Per package: the dist-tags.latest version, that version's ISO date in time{}, maintainers.length, and the dependency count of versions[latest]. Pulled 2026-10-13. "Mean gap" is the average spacing between releases in days and "total releases" counts the time{} entries; both are reading aids computed at pull time, not verified cells.

Release dates are written absolute, and ages in the prose below are stated against 2026-10-13. A "days ago" cell is true the day it is written and wrong every day after — the download tables on this site are re-checked in CI against fixed windows, and a table that drifts daily could never survive that gate honestly. So this table can be re-checked too: scripts/verify-registry-meta.mjs compares every version, date, maintainer, and dependency cell against the registry on each build.

The table

Read the middle of the table, not the end. On the verified download chart, papaparse grew +490% and shipped 50 days before the measurement date; d3-dsv grew +561% and has not shipped since 2021-06-05 — over five years. Both are true simultaneously, and the download chart hides the second fact completely.

What the numbers actually support

Zero-dependency is the norm, not a flex. csv-parse, csv-stringify, and papaparse all ship with no runtime dependencies. For this category that is table stakes: a parser with four transitive deps (csv, the meta-package) is buying you an alias, not a feature.

One maintainer is the norm too. Five of the eight are single-maintainer. That is not a red flag for a format this stable — RFC 4180 is not going to change — but it does mean "who merges my PR" has one answer, and fast-csv (3) and papaparse and d3-dsv (2 each) are the only ones with any redundancy. Treat maintainer count as a bus-factor note, not a quality signal.

papaparse's mean gap is undefined because it has exactly one release in the trailing window; the — is arithmetic, not missing data. Its 50 total releases across a much longer life, with the newest 50 days back as of 2026-10-13, is the profile of a finished library that still gets patched. That is a fine thing to depend on.

The d3-dsv case deserves specifics. Released 2021-06-05, and at +561% it is still the third-fastest grower on the download chart — behind only fast-csv (+784%) and @fast-csv/parse (+782%). It is not abandoned in any way that hurts you: DSV is a fixed format, the code is small, and it has three dependencies (d3-dsv → d3-array, commander, internmap) which is the one genuinely odd part — a CLI flag dependency inside a parse library. If you import it for the parser you are still pulling the commander.

neat-csv at 12 total releases, last shipped 2021-10-18 is the profile of a package nobody intends to touch again. Fine to use, wrong to build on.

Where this site's parser sits

By these axes it is neither: zero dependencies, zero releases on a schedule, and one person who will notice a bug report. That is the honest framing — a browser-side converter does not need a release cadence, but it also has no review process, which is precisely why the RFC 4180 deviations are written down rather than left to be discovered. The failure mode of a one-maintainer tool is not malice, it is that nobody looked at the trim.

What this page cannot tell you

• Registry maintainers is a publish-permission list, not a team. A large org publishing under one bot account shows as 1. It understates projects with many committers and one releaser.
• Release count rewards churn. A package that ships 150 releases is not better maintained than one that ships 50; it may just ship noise. Use the date and the gap, not the total.
• Time-since-last-release is ambiguous by construction. It means both "finished" and "abandoned" and metadata cannot distinguish them. d3-dsv is finished; something else with the same number might be rotting. The tiebreaker is whether open issues get answered, which is not in this document.
• None of this is a security signal. A package can release weekly and still take a transitive dependency hit; a five-year-old one may have zero advisories. Check the advisory feed for anything you actually ship, on every build, not on the release calendar.

Decisions this does and doesn't settle

It settles one thing: if you are choosing a CSV dependency for something that will outlive the current framework, look at the release date before you look at downloads, and treat a five-year gap as a question rather than a verdict.

It does not settle which parser is fastest, which is most correct, or which handles the most dialects. Those are measurable and the deviations page shows the method for the third one; the first two need a benchmark harness this site does not currently have, and I would rather say that than quote someone else's numbers as if they were mine.