Update to ESLint 10 and TypeScript 6

[jhnns]

Just a quick update what's currently blocking. This is the AI output:

TypeScript 6

Partly, by fixing the real peer cap — but one dependency still blocks a fully strict install.

typescript-eslint
On 8.57.x, peers are typescript: ">=4.8.4 <6.0.0", so TypeScript 6 is rejected.
From 8.58.0 onward, peers are typescript: ">=4.8.4 <6.1.0", so TypeScript 6 is allowed.
No overrides and no --force are required for typescript-eslint once you’re on ≥8.58.

@eslint-react/eslint-plugin@2.13.x
It still declares typescript: ">=4.8.4 <6.0.0". That directly conflicts with TypeScript 6, so npm install fails with ERESOLVE until something gives.
package.json overrides do not rewrite another package’s peer ranges, so they don’t remove this conflict.
@eslint-react/eslint-plugin@4.x allows typescript: "*", but it requires ESLint 10, while your stack (e.g. eslint-plugin-react, eslint-plugin-react-hooks) is still on ESLint 9 peers, so that’s not a drop-in upgrade yet.

ESLint 10

Here’s what actually gates ESLint 10 for this repo, going by your current dependencies and each package’s peerDependencies on npm today.

These are the ones that do not declare ESLint 10 on their latest tag, so a strict install with eslint@10 will disagree with their peers:

Package	Declared eslint peer (latest)
eslint-plugin-react	^3 || … || ^9.7 — no 10
eslint-plugin-react-hooks	^3 … || ^9.0.0 — no 10
eslint-plugin-jsx-a11y	^3 || … || ^9 — no 10
@tanstack/eslint-plugin-query	^8.57.0 || ^9.0.0 — no 10

Your React preset pulls in the first three; TanStack rules pull in the fourth. Until those maintainers ship releases whose peers include ^10.0.0 (or a range that includes 10), ESLint 10 is blocked if you care about clean peer resolution (same kind of issue you hit with TypeScript 6).

@eslint-react/eslint-plugin is the opposite problem

• v2.x (what you use) is aimed at ESLint 8–9 and still has the tight TypeScript < 6 peer.
• v4.x expects eslint: ^10.0.0 and typescript: *, so it fits ESLint 10, but only after the React core plugins above allow 10.

So eslint-react isn’t “blocking 10” in the abstract — v4 is the ESLint 10 line — but you can’t land on it comfortably until the rest of the React ESLint stack allows 10.

Already fine for ESLint 10 (by peers)

Examples from your tree: eslint-config-prettier, eslint-plugin-unicorn, @eslint/compat, typescript-eslint, @vitest/eslint-plugin, eslint-plugin-playwright, eslint-plugin-react-refresh (^9 \|\| ^10), eslint-plugin-react-you-might-not-need-an-effect, etc.

Tooling you’d bump with ESLint 10

@eslint/js on latest is pinned to eslint: ^10.0.0, so moving the repo to ESLint 10 means taking @eslint/js v10 alongside eslint v10, not staying on the v9 line.

---

Bottom line: what prevents moving to ESLint 10 today is mostly the React + a11y + TanStack ESLint plugins, whose stable peer ranges still stop at 9. Once those publish ESLint 10–compatible majors/minors, you can adopt eslint@10, @eslint/js@10, @eslint-react/eslint-plugin@4, and drop a lot of the peer friction you worked around for TypeScript 6.

[leomelzer]

eslint-plugin-jsx-a11y seems the only missing bit: jsx-eslint/eslint-plugin-jsx-a11y#1075

[jhnns]

We could consider switching to https://github.com/es-tooling/eslint-plugin-jsx-a11y-x ...

[jhnns]

This was closed too eagerly 😁

[jhnns]

These are our options regarding a11y tooling:

1. eslint-plugin-jsx-a11y (what you have)

• The ecosystem standard. ~34M weekly downloads, ~11k dependents, 4 maintainers.
• Rules: ~40 rules, split into recommended and strict configs. This is the widest rule set of any option.
• Maintenance: mixed signal. Last npm release was v6.10.2 in Oct 2024 — 18+ months without a release. Snyk labels it "sustainable" but flags the release gap. Commits still happen (last ~3 months ago).
• The real problem: no official ESLint 10 support yet (ESLint 10 shipped Feb 2026). It's the most-referenced blocker in the ecosystem right now (137+ 👍), with several community PRs open but unmerged. On ESLint 9 (where you presumably are) it's fine; the moment you want ESLint 10 you'll need overrides or a fork.

2. eslint-plugin-jsx-a11y-x (modern fork, by es-tooling)

• Drop-in fork with rule parity (~40 rules, same names, recommended/strict).
• More modern internals: replaces third-party deps with built-in tooling, flat-config only (dropped legacy eslintrc), and already ships ESLint 10 support (April 2026).
• Maintained by es-tooling / 43081j & jdufresne — small in stars (~32) but actively released.
• Trade-off: tiny community vs. the original, so you're betting on the fork's longevity. But it's the natural upgrade path if the upstream ESLint 10 stall bothers you.

3. Biome (a11y rule group)

• Rust, built-in, extremely fast, no ESLint needed.
• ~25–30 a11y rules, inspired by jsx-a11y but not full parity — the commonly cited gap is exactly accessibility coverage. Fine for typical apps, not enough if a11y is a hard requirement.
• Only relevant if you'd move off ESLint entirely, which your @eslint-react + typed-linting setup argues against.

4. Oxlint (jsx-a11y plugin)

• Rust, ports jsx-a11y rules (and as of May 2026 maps jsx-a11y-x → jsx-a11y), off by default.
• Rule coverage is partial (not all ~40 implemented). Positioned as a fast pre-filter alongside ESLint, not a replacement for the full rule set.

Bottom line

Package	Rules	Maintenance	ESLint 10	Notes
eslint-plugin-jsx-a11y	~40 (most)	Sustainable but stalled releases	❌ (PRs open)	Current standard
eslint-plugin-jsx-a11y-x	~40 (parity)	Active, small	✅	Modern fork, flat-only
Biome a11y	~25–30	Very active	n/a (own tool)	Not full parity
Oxlint jsx-a11y	partial	Very active	n/a (own tool)	Fast, incomplete

For maximum rules, eslint-plugin-jsx-a11y and its fork -x tie (parity), and both beat Biome/Oxlint.

For "modern + well-maintained" in your ESLint-flat-config setup, eslint-plugin-jsx-a11y-x is the strongest fit: same rules you already enable, but it's actively released and unblocks ESLint 10 whenever you bump. Given the repo's philosophy (objective correctness, minimal churn), I'd keep the original for now and only swap to -x when the upstream ESLint 10 stall actually blocks you — the migration is essentially a rename of jsxA11yPlugin import plus the jsx-a11y-x rule prefix in eslint/rules/react.js.