Eslint v9 vs. v10

[dmijatovic]

ESLint Assessment

We are currently seeing peer dependency errors during package installation because our core plugins (like eslint-config-next and eslint-plugin-jsx-a11y) do not officially support ESLint v10 yet.

Below is the technical breakdown of our paths forward composed using Google AI-mode. At this point I am in favor of downgrading to eslint v9.

1. Core Comparison Matrix

Metric	Option A: Downgrade to ESLint v9	Option B: Force / Customize v10
Security Risk	Zero Risk. v9 receives fully supported security patches from the core team until August 2026.	Low-to-Medium. Customizing ignores package locks, increasing risk of supply-chain issues or uncaught sub-dep vulnerabilities.
Pipeline Stability	Perfect. All plugins natively resolve their peer trees. Zero warnings in local terminals or CI logs.	Brittle. Future minor updates to sub-plugins can break the custom setup overnight, breaking build scripts.
Runtime Reliability	Guaranteed. Lint rules run as intended because APIs like context.getFilename() exist natively.	Risky. Sub-plugins could throw silent runtime execution faults, skipping crucial code quality checks entirely.
Effort Needed	Instant. Adjusting two numbers in package.json resolves all local errors immediately.	High Overhead. Requires managing manual overrides and routinely validating rule integrity across major packages.

---

2. Pros & Cons Deep Dive

Metric	Option A: Downgrade to ESLint v9 (Recommended)	Option B: Force / Customize ESLint v10
Pros	- 100% aligned with Vercel's current stable ecosystem. - Native peer dependency resolution. - No changes needed to our modern Flat Config format. - Zero risk of silent lint failures in CI pipelines.	- Keeps the repository on the absolute latest major version. - Access to v10's enhanced language-aware rules. - Eliminates the need for a secondary migration task later.
Cons	- Requires a brief technical debt task to bump to v10 before the v9 EOL date (August 6, 2026).	- Requires managing brittle package manager overrides. - High risk of minor plugin updates breaking CI build scripts. - Risk of sub-plugins throwing silent runtime errors due to removed v10 APIs.
Effort	Low: Changing two version strings fixes the repository instantly.	High: Ongoing maintenance to manually track and validate rule integrity.
Recommendation	Proceed with this path. It ensures pipeline stability while maintaining a clean, modern Flat Config base.	Avoid for now. Forcing peer overrides puts the project in an unsupported and un-tested state.

---

3. Long-Term Evaluation: Alternatives to ESLint for Large Projects

If plugin version bottlenecks continue to impact our development many large enterprise repositories are actively migrating to high-performance, Rust-based tooling:

Alternative Linter	Language Built On	Core Selling Point	Notable Adopters & Ecosystem
Biome	Rust	15x-25x faster than ESLint/Prettier; all-in-one linter, formatter, and organizer with zero dependencies.	Widely adopted in massive monorepos; formally recommended by the Next.js team as a core native linting alternative.
Oxc (oxlint)	Rust	50x-100x faster; works instantly out of the box with zero configuration required.	Rapidly adopted by large tech platforms (e.g., Shopify) to dramatically reduce CI/CD pipeline build times.
Quick-Lint-JS	C++	Ultra-low latency; designed to find bugs immediately inside the editor as you type.	Used heavily by independent developers and teams prioritizing instantaneous editor feedback over stylized formatting rules.

Why large projects are moving to Rust-based linting:

1. Performance at Scale: Rust engines run in milliseconds rather than minutes, slashing CI/CD runner overhead for large multi-package apps.
2. Unified Tooling: Biome replaces ESLint, Prettier, and import-sorters under a single tool, permanently eliminating node_modules peer-dependency deadlocks.

4 Evaluation: Migrating from Next.js ESLint to Biome

Below is a technical feature-parity assessment comparing our current Next.js ESLint configuration against Biome, focusing specifically on React, React Hooks, and Accessibility (a11y).

Core Feature Comparison Matrix

Feature Domain	ESLint Configuration (Current)	Biome Compatibility Status	Core Capabilities & Remaining Gaps
React Core Rules	Fully Supported (eslint-plugin-react)	Partial Support	Maps major React rules natively (JSX structure, keys, component casing). However, it lacks support for modern React 19 Compiler rules (eslint-plugin-react-compiler).
React Hooks	Fully Supported (eslint-plugin-react-hooks)	Full Support	Fully covers hooks rules. Biome's useHookAtTopLevel replaces rules-of-hooks, and useExhaustiveDependencies replaces exhaustive-deps.
Accessibility (a11y)	Fully Supported (eslint-plugin-jsx-a11y)	High Support	Features a dedicated a11y rule group matching roughly 85% of jsx-a11y. Catches alt text, aria attributes, and form labels, but misses niche media captions.
Next.js Framework Optimizations	Fully Supported (@next/eslint-plugin-next)	No Support	Completely lacks Next.js-specific framework rules. It will not warn you about using standard HTML image tags instead of next/image or raw script tags instead of next/script.

---

Pros & Cons of Adopting Biome

Pros:

• Execution speed is 15x to 25x faster than ESLint, significantly accelerating local editor feedback and CI/CD build pipelines.
• Acts as a unified tool replacing ESLint, Prettier, and import sorting, completely eliminating node_modules peer-dependency deadlocks.
• Extremely low maintenance footprint with zero secondary dependencies to manage.

Cons:

• Misses crucial Vercel-specific framework warnings that safeguard performance and image layout optimization.
• Cannot enforce component-level syntax rules for projects leveraging the automated React Compiler.

---

Package popularity

[ewan-escience]

At this point I am in favor of downgrading to eslint v9.

Too much text. Why are you in favour of this?