Skip to main content
ESLint Interlace

Compatibility

Which ESLint and Node.js versions Interlace supports — and the policy that decides what stays in the matrix.

What you can install Interlace on

Interlace is published as ~37 npm packages (20 ESLint plugins + 11 MCP servers + 6 supporting tools). Every published package declares the same compatibility surface so a viewer can answer "will this work in my repo?" in one read.

Last data refresh

2026-05-09 — npm download share refreshed weekly via npm run stats:eslint-versions. The numbers below come from a live npm-registry pull, not a marketing claim.


ESLint version matrix

ESLint majorWeekly downloadsShareStatus
v1011.8M9.24%✅ Supported (forward-looking)
v976.9M60.4%✅ Supported (current default)
v830.9M24.3%✅ Supported (legacy active)
v7 and older7.7M6.1%❌ Unsupported (EOL)

All published packages declare "eslint": "^8.0.0 || ^9.0.0 || ^10.0.0" as a peer dependency. No exceptions, no per-plugin variance.

Together: ~94% of weekly ESLint downloads

v8 + v9 + v10 cover 94% of every npm install eslint happening today. If you're on a supported version, every Interlace plugin works.


Node.js compatibility

Node.jsStatusNotes
24.x✅ Active developmentWhat this repo's CI runs against
22.x LTS✅ SupportedRecommended for production users
20.x LTS✅ SupportedLong-term-stable baseline
18.x✅ Supported (minimum)Lowest declared engines.node across all packages
≤ 17❌ UnsupportedEOL upstream

The 18.x floor is set by every package's engines.node: ">=18.0.0". Bumping the floor uses the same gate logic as ESLint majors — a deliberate decision, not silent drift.


The two-rule policy

A major version is supported when either of these holds:

The 20% gate

The version has ≥20% of weekly downloads on npm. v8 (24%) and v9 (60%) earn their place this way. Versions that drop below 20% on two consecutive refreshes become deprecation candidates.

Forward-looking exception

The version is the next major after a currently-supported one. v10 qualifies today (the future of v9). We ship support pre-emptively so users can upgrade ahead of the curve, not behind it.

A supported major is in our peerDependencies, our benchmark matrix, and our CI matrix. Removal requires both a sustained share drop AND a successor that itself meets the criteria above — never one without the other.


How the matrix stays honest

SurfaceWhat it does
Per-package peerDependenciesAll 37 packages declare the same range. A package that violates the policy fails scripts/check-version-alignment.ts (npm run check-versions).
Benchmark fixturesbenchmarks/suites/ilb-arena/eslint{8,9,10}-compat/ — one full ILB-Arena fixture per supported major. Drift on any version surfaces as a benchmark regression, not a runtime surprise.
CI matrixeslint-version-matrix.yml runs ILB-Arena + ILB-Juliet across node × eslint cells [22, 24] × [8.x, 9.x, 10.x] on every PR.
Stats refreshnpm run stats:eslint-versions re-fetches the npm download share so the gate decision uses fresh data.
Policy docThe full deprecation pipeline lives in docs/ESLINT_VERSION_SUPPORT.md.

Interlace is compatible with more than just ESLint majors. Each layer below gets its own matrix:


Why this matters

A docs site can claim "supports the latest ESLint." That's not enough — every plugin in your package.json peer-dep range has to actually publish that range, and every benchmark you trust has to actually run on every version you claim to support. The matrix above is the contract; the CI gates are the enforcement.

Bringing this onto the docs site means an evaluating engineer can answer all three questions in one read: which ESLint major can I use, which Node version do I need, and how confident can I be that this won't drift?