Skip to main content
ESLint Interlace
Getting startedConcepts

Runtime Portability

One rule, multiple engines — ESLint today, oxlint now, TSC plugin host eventually. How Interlace makes the engine an implementation detail.

The core commitment

Rules are portable. Runtimes are not. We commit to rule semantics; we do not commit to a single engine.

The Rust/Go rewrite wave — oxlint, Biome, swc, the Go port of TSC — is the largest re-platforming JavaScript tooling has seen since ESLint shipped in 2013. Most plugin authors are betting on one engine. Interlace ships to two, and grades them against a parity contract.


Two tiers, two engines

Every rule we ship belongs to exactly one tier. The tier is part of the rule's metadata, surfaced on its docs page, and used by CI to route the rule to the correct engine.

TierEngineSubstrateWhen it runs
Fastoxlint primary; ESLint floorAST onlyEditor on save, pre-commit, fast CI
DeepESLint primary; TSC 7 host eventuallyAST + type graph + scope + dataflowCI deep leg, on-demand, IDE background

No rule straddles tiers. A rule that needs type information is deep, period. If a fast-tier rule quietly relies on types, that's a regression we fix — not a graceful degradation we ship.


The parity contract

A rule with runtimes: [eslint, oxlint] must produce identical diagnostics on identical input across both engines. Drift is a build failure, not a footnote.

This is enforced by:


Why this matters to you

  • Your editor stays fast. Fast-tier rules run on save under oxlint's sub-second budget.
  • Your CI stays correct. Deep-tier rules run under ESLint where the type graph and dataflow live.
  • Your investment survives a runtime swap. When TSC 7 ships a plugin host, our deep-tier rules port — the rule semantics don't change.

The full philosophy

The complete contract — including what "identical" means, how drift gets resolved, and the TSC 7 vision — is documented in INTEROP_PHILOSOPHY.md at the repository root.