[Design Discussion] Evaluation: Replacing ESLint with Oxlint in Frontend

[kavix]

Related Feature Issue

#4654

Problem Summary

The frontend currently utilizes ESLint for linting. ESLint's dependency tree is relatively large, and as the codebase grows, linting contributes to longer local development and CI execution times. This evaluation assesses oxlint (a Rust-based linter from Oxc) to determine if it can provide comparable lint coverage while improving developer experience and CI performance.

High-Level Approach

Oxlint (v1.77.0) was installed as a dev dependency alongside ESLint, and a .oxlintrc.json configuration was created to mirror the existing rule coverage across React, TypeScript, Vitest, JSX accessibility, and import rules. Execution times were then benchmarked across the 2,042 .ts/.tsx files in the @thunderid/frontend monorepo to analyze rule parity and identify missing gaps.

Local Execution Benchmarks (macOS Apple Silicon, 8 CPU threads, Node.js v20.11.0):

Run Metric	ESLint (Flat Config + Type-Aware)	oxlint v1.77.0 (Non-Type-Aware)	Speedup
Run 1 (Warmup)	178.52 s	1.896 s	94.1x
Run 2	177.68 s	1.232 s	144.2x
Run 3	179.10 s	1.192 s	150.2x
Median Time	178.52 s (~3 mins)	1.232 s (~1.2s)	~144.9x faster

Estimated CI Execution & Resource Impact (GitHub Actions ubuntu-latest 2-Core):

Metric	Existing ESLint Pipeline	Potential oxlint Pipeline
CI Lint Job Time	~4 - 6 minutes	~3 - 5 seconds
Dependency Footprint	~50+ npm packages (~180MB node_modules)	Single binary executable (~15MB)
Memory Footprint	~2GB - 4GB (Heap OOM risk)	~120MB peak RAM natively

Additional Technical Findings:

• Parser Reliability: Successfully parsed all 2,042 target files, including complex TypeScript generic types and modern React syntax, with zero AST parser errors.
• Rule Efficacy: Advanced AST rules, such as import/no-cycle, were successfully validated, identifying 4 pre-existing circular import cycles in under 500ms.

Architecture Overview

Currently, full replacement is blocked. Oxlint operates natively without Node.js overhead for core parsing, but it currently lacks two critical required features:

1. Custom Copyright Header Rule (@thunderid/copyright-header): Required for open-source governance. Custom AST rule execution via JS plugins is currently incompatible.
2. Type-Aware Linting: The frontend relies on type-aware checking (@typescript-eslint/recommendedTypeChecked), which oxlint does not yet support.

Security Considerations

No security regressions were identified. Oxlint natively supports rules equivalent to ESLint's no-danger and jsx-a11y rules, ensuring secure React usage is still strictly enforced.

Impacted Areas

• @thunderid/frontend (Local Developer workflow)
• CI/CD linting pipelines

Alternatives Considered

Hybrid Linter Setup
Instead of a full replacement, a dual setup can be adopted:

• Pre-commit / Fast CI: Utilize oxlint for instant sub-second developer feedback on JS/TS AST errors, React Hooks rules, and circular dependency checks.
• Comprehensive CI Validation: Retain ESLint in CI for type-aware safety checks and copyright header verification.

Questions for Community Input

1. Should this hybrid setup (oxlint for quick local checks, ESLint for full CI checks) be adopted immediately to accelerate development?
2. Are there any other critical ESLint rules that were missed which would prevent the adoption of oxlint?