The CSS Toolchain Is Maintained by One Person Each

Download counts tell you how many people pull a package. They cannot tell you whether anyone is still home. In the CSS category the answer turns out to be different from every other category on this site, and it is not the answer you would guess.

Every metadata cell is the registry's own value for the package's latest dist-tag, read on 2026-10-13 from registry.npmjs.org/<pkg>. Ages are stated against that fixed date and never as "X days ago", because a relative cell is true the day it is written and wrong every day after. Download cells are the published window 2024-10-01 to 2026-10-10 (first 30 days against last 30), pulled 2026-10-12 — same numbers as the libraries page.

The ten packages, as the registry has them

Here, stale is not the risk — concentrated is

Across the other categories on this site the pattern was "huge downloads, old release". CSS breaks the pattern in the worst available direction.

postcss is 1.342B downloads in the last 30 days, growing +315%, and it has exactly one publish account. Not stale — it shipped 2026-10-12, one day before this was pulled. So the risk is not that nobody is maintaining it. The risk is that one person is maintaining the plugin host underneath almost every CSS build in the language, including autoprefixer and cssnano, which are themselves in this table. Freshness and single-point-of-failure are not opposites, and this row is both at once.

autoprefixer is the same shape: one publish account, 287.5M a month, +220%, released 2026-09-15, and it carries 5 dependencies — the heaviest tree in this table after postcss itself. Autoprefixer's whole job is knowing which browser prefixes are current, which means its correctness decays on a schedule it does not control. A single maintainer plus a five-dependency browserslist chain is the most load-bearing pair in this table.

lightningcss: one publish account, +130× growth — the fastest multiple here — 751.5M a month, released 2026-07-20 (85 days). It is a Rust parser exposed to JS, so "one maintainer" also means one person who can read the part that actually parses your CSS.

cssnano: the only team, and the slowest growth

cssnano has 8 publish accounts, the most here, released 2026-10-12, and it has the second-lowest growth in the table at +78%. More maintainers bought reliability, not adoption. The minifier market is not reward-ing team size; the single-maintainer Rust parser next to it grew 130× while cssnano grew 78%.

If you are choosing a minifier on maintenance-headcount grounds, this table says you would be optimising for the axis nobody is buying.

Frozen is not always abandoned

clean-css shipped 5.3.3 on 2023-11-30 — 1,048 days before measurement — and still grew +56% to 100.3M a month. Two maintainers. A CSS minifier is a nearly closed problem: there is little left to discover, and the safety properties that matter are documented on the minification safety page.

normalize.css is the extreme: 8.0.1, released 2018-11-09, 2,895 days, one maintainer, 6.026M a month, still +26%. It is not abandoned; it is finished, and browsers did what it asked them to do, which is why its own page argues you probably should not need it. Read the reset/normalize guide for that argument — it is the strongest case on this site of a package that is right to keep using and right to stop using.

Both of these are what a >1000 days cell should make you think: not "broken", but "nobody will fix it if it breaks". For a normalize file whose content is three rules, that is a fine trade.

The only package here losing users

purecss was released 2026-09-28 — 15 days before the measurement date, actively maintained, three maintainers, zero dependencies — and downloads are down 31% (0.13M → 0.09M). It is the one row where maintenance is not the variable. The single-maintainer utility framework grew +262% while the three-maintainer one shrank.

That is the caution attached to every other claim on this page: maintenance input does not predict adoption, and adoption does not predict maintenance. Use these cells to find out who would fix it, not to guess what wins.

What this does and does not prove

A release date is a fact; what it implies is not.

npm's maintainer count measures publish access, not effort. One account can sit behind a hundred-committer project, and a large count can be a bot roster — so cssnano's 8 and postcss's 1 may describe organisational choices more than resilience. Zero dependencies is the one clean property here: seven of these ten have nothing below them, and for a build-time tool that is a genuine supply-chain fact rather than a vibe.

What the counts do establish, narrowly: the three most load-bearing packages in this table — postcss, autoprefixer, lightningcss — are each held by one publish account, at 1.342B, 287.5M and 751.5M downloads a month. Not "could be a problem". The registry says there is one credential between your build and nobody.

So the practical version: know which single-maintainer packages are in your build path rather than your dependency graph, and make sure you can rebuild without them. For CSS that usually means pinning, because a CSS toolchain package that stops releasing is a package that stops tracking browsers — see CSS performance for where that shows up.

Related: CSS libraries in 2026, CSS alternatives, minification safety, reset vs normalize, CSS performance.

Metadata came from registry.npmjs.org on 2026-10-13 and is re-checked cell-by-cell by scripts/verify-registry-meta.mjs. Download cells are verified by scripts/verify-npm-figures.mjs against the window above. Ages were computed against the fixed date 2026-10-13, not against "today". Prose readings ("load-bearing", "finished", "frozen") are argument, not measurement, and the verifier deliberately leaves them alone.