Compatibility
Which lint engines, ESLint majors, 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.
Compatibility here covers three axes: which lint engine runs your rules (ESLint floor, Oxlint automated peer, Biome + TSC native on the roadmap), which ESLint major you're on, and which Node version the host requires.
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 major | Weekly downloads | Share | Status |
|---|---|---|---|
| v10 | 11.8M | 9.24% | ✅ Supported (forward-looking) |
| v9 | 76.9M | 60.4% | ✅ Supported (current default) |
| v8 | 30.9M | 24.3% | ✅ Supported (legacy active) |
| v7 and older | 7.7M | 6.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.js | Status | Notes |
|---|---|---|
| 24.x | ✅ Active development | What this repo's CI runs against |
| 22.x LTS | ✅ Supported | Recommended for production users |
| 20.x LTS | ✅ Supported | Long-term-stable baseline |
| 18.x | ✅ Supported (minimum) | Lowest declared engines.node across all packages |
| ≤ 17 | ❌ Unsupported | EOL 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.
Lint engine matrix
Interlace is engine-portable by design. The same rule library runs under multiple linters with a CI-enforced parity contract — drift fails the build. Statuses match the canonical support matrix in INTEROP_PHILOSOPHY.md.
| Engine | Status | What this means |
|---|---|---|
| ESLint v8 / v9 / v10 | ✅ Floor | Every rule runs here. Every rule's tests are authored against this engine. |
| Oxlint (Rust) | ✅ Automated peer | Shared rules have CI-enforced diagnostic parity via oxlint-parity.yml. The gate flips advisory → blocker once Oxlint ships 1.0 and the shared-rule count reaches ≥ 20. |
| Biome (Rust) | 🟡 Reserved peer | First-class portability target. Parity adapter on the roadmap; until it ships, support is best-effort. |
| TSC native plugin host (Go) | 🔭 Watching | The Go port of the TypeScript compiler (tsgo) is the inevitable second runtime for deep-tier rules once stable. Re-evaluated when it ships; deep-tier rules port without API change. |
| swc / deno_lint | ❌ Not a target | Out of scope. swc is a compiler, not a lint host. deno_lint is forked from a separate rule corpus. |
The re-platforming wave runs on two languages
The Rust/Go rewrite of JavaScript tooling has two camps: Oxlint and Biome are Rust-based linters; the TypeScript native compiler port (tsgo, tracking toward TSC 7) is Go-based. Interlace targets all four engines from one rule library — rules are portable, runtimes are commodity.
The parity contract, how drift is detected, and the TSC 7 vision are documented on the Runtime Portability page.
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
| Surface | What it does |
|---|---|
Per-package peerDependencies | All 37 packages declare the same range. A package that violates the policy fails scripts/check-version-alignment.ts (npm run check-versions). |
| Benchmark fixtures | benchmarks/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 matrix | eslint-version-matrix.yml runs ILB-Arena + ILB-Juliet across node × eslint cells [22, 24] × [8.x, 9.x, 10.x] on every PR. |
| Stats refresh | npm run stats:eslint-versions re-fetches the npm download share so the gate decision uses fresh data. |
| Policy doc | The full deprecation pipeline lives in docs/ESLINT_VERSION_SUPPORT.md. |
Related compatibility surfaces
Interlace is compatible with more than just ESLint majors. Each layer below gets its own matrix:
MITRE CWE Compatibility
Every security rule maps to one or more CWE identifiers, surfaced in machine-readable form for SARIF / GHAS / GitLab consumers.
SDK Compatibility
Per-SDK weekly tests (pg / mongodb / express / jwt / nestjs / vercel-ai / lambda) catch upstream breaking changes before users do.
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?