Regex Tooling in 2026: The Library That Stopped Growing

Most "state of regex" writing is anecdote assembled from old Stack Overflow answers. This page uses a harder source: the npm downloads API, which counts what machines actually installed. Pull it yourself and check the figures — the window is 2024-10-01 to 2026-10-10, each number a monthly total comparing the window's first 30 full days with its last 30.

Two limits on that source. Downloads are installs, not users: a package pulled by every container in a build farm counts once per container. And the API cannot separate a package chosen deliberately from one dragged in transitively. Both caveats apply throughout, which is why the download data is paired with measurements taken on this site's own runtime — those parts are labelled.

The table

Read the ordering, not just the extremes. xregexp — the batteries-included regex library, installed when standard regex is not enough — grew +19%, while formatter, parser, and repair tooling grew +202% to +3522%. uuid at +123% is a useful floor: a package close to a utility of nature, growing roughly with the number of projects. Regex library growth sits below that floor; everything that consumes syntax sits far above it.

That gap is the finding. The rest is interpretation — explicitly labelled, because downloads establish direction, not cause.

Interpretation 1: the syntax finished shipping

What the engine behind this tester accepted and rejected, compiled at runtime with new RegExp, measured 2026-10-11 on Node v24.21.0 with V8 13.6.233.17-node.53 — the class of engine every evergreen browser ships:

Accepted: lookbehind (?<=a) · named groups (?<y>\d{4}) · \p{Script=Greek} with the u flag · \p{L} with the v flag · duplicate group names under v · set difference [\p{L}--q] under v · named backreference \k<a> · dotAll via s.

Rejected — threw at compile time: atomic groups (?>a*) and possessive quantifiers a*+.

Every accepted item is years old: lookbehind and named groups arrived back in ES2018, and the v flag followed later. The two rejected items have been in the Perl family for decades and are still absent, and TC39's proposals list has nothing in flight that would change how you write a pattern this year. The regular expressions section of MDN reads like a closed book, not a roadmap.

For a library selling "more than standard regex", that is an existential problem. When the standard absorbs the feature set, the library's value proposition stops growing. A candidate explanation for +19%, not proof of it — but it fits the shape of the data, which is: nothing left to add.

Interpretation 2: the platform ate the library

xregexp historically sold conveniences JavaScript eventually shipped natively: named groups, Unicode property escapes, more disciplined flag handling. Each native arrival removed a reason to install the library, and installs are what the API counts.

Not a regex story specifically. The current demonstration is CSS: the :has() selector reached browsers and made a category of DOM-querying helpers optional overnight. Same mechanism, different layer: the platform implements the feature, the wrapper becomes a shim, installs decay toward the existing base.

Honest counter-argument: xregexp is still maintained, and +19% is growth, not decline. A platform can eat a library's reason to exist without eating its users for years.

Interpretation 3: growth moved to things that consume patterns

If library growth is flat and consumer-tool growth is 200–3500%, where did the energy go? Three signals — reading the data, not measuring a cause.

prettier at +202% — the market leader for tooling that parses your code and does something to it. It also parses regex literals as part of formatting JavaScript, so part of this number is arguably formatting budgets rather than regex interest. I cannot separate those with this API, and I would rather flag it than quietly claim the number.

jsonrepair at +928% — repair is a category now. Nothing that writes correct input grew 9× to explain that; something producing almost-correct input did. Regex-adjacent in a real way: generation-heavy workflows emit patterns that are syntactically close and semantically wrong, and the market pays to fix and flag them rather than to author them.

lightningcss at +3522% — the largest move here is a parser fast enough to be vendored inside other tools. When a low-level dependency outruns everything built above it, the tools above are swapping internals — and the tools that will consume patterns at scale are being built on that foundation now.

Together: a market shifting from providing syntax to judging syntax — testers, linters, generators, repair tools. regex101 has occupied the judging niche far longer than any of these packages; what changed is that judging is now automated enough to ship as a dependency.

Measured: finished syntax is not finished problems

The download API cannot see runtime behaviour, so I measured it. Pattern /^(a+)+b$/, input "a" repeated n times then "x", compiled with new RegExp, 2026-10-11:

n=16   1.1ms
n=18   1.1ms
n=20   4.1ms
n=22  16.6ms
n=24  66.2ms
n=26 265.4ms

The first two rows sit at the measurement floor; from there the cost is roughly 4× per +2 characters. That is the exponential signature of re-partitioning the a-run on failure — and it is a rejection path, which is why it hides from tests that use valid input. I am not extrapolating past n=26; the curve keeps doing what it is doing. Timings drift run to run: order of magnitude, not a constant. Full anatomy in the ReDoS protection guide.

Put the two measurements side by side — that collision is the point:

• The syntax is finished: no atomic groups (?>a*), no possessive quantifiers a*+, nothing in flight.
• The engine is still backtracking: rejection still costs roughly 4× per two characters.

In engines with atomic groups, the fix is to keep the pattern and forbid re-partitioning. RE2 solves it by refusing to backtrack at all. JavaScript offers neither, so the only remaining fix is seeing the explosion before you ship it — a verification problem, not a syntax problem. Finished syntax does not mean finished work; it means the work moved to the checking layer.

What I'd do with this

• If you maintain a regex library: the growth is not in new syntax, because there is not any. It is in what you can say about a pattern — safety analysis, explanation, portability checks. A library that only adds sugar competes with a language that stopped needing sugar.
• If you're choosing dependencies: treat "more regex features" as a suspect pitch in 2026. Test what your engine accepts the way the table above was produced, and keep patterns portable across the engines in the alternatives guide.
• If you're building tooling: build the consume side — linters, testers, generators, repair. Two years of install data points there, and it is where the unsolved problem (catching exponential patterns before production) lives.

Downloads pulled 2026-10-11 from the npm downloads API, 30-day windows; installs, not users. Syntax support and timings measured locally on Node v24.21.0 (V8 13.6.233.17-node.53) the same day. Everything under an "Interpretation" heading is my reading of the data, not a measurement.