Developer ships React 19 linting continuation for ESLint 10 as upstream stalls

A developer has published @ternaus/eslint-plugin-react, an independent continuation of eslint-plugin-react built for React 19 projects running ESLint 10. According to the author's post on dev.to, the release fills a gap left by the upstream plugin, which still declares support only through ESLint 9.

What broke

ESLint 10 removed deprecated rule-context APIs, and the current eslint-plugin-react release, version 7.37.5, can crash under the new major version with a TypeError reporting that contextOrFilename.getFilename is not a function. The author writes that an upstream compatibility issue was opened on February 7, 2026, and remained open more than six months later as of August 23; a pull request filed on July 30 was also still pending.

Rather than wait, the author forked the upstream repository, preserving its Git history, MIT license and attribution, and now maintains the project independently.

A deliberately narrow contract

The new package supports React 19 and above, ESLint 10, Biome 2.5.8 or later, and Node.js 22.13, 24 or 26, with flat config only. React 18, ESLint 9 and .eslintrc files are explicitly outside the contract.

The design assumes the two-tool setup the author runs in production Next.js 16 and React 19 codebases: Biome serves as the primary formatter and linter for general JavaScript, TypeScript and JSX, while ESLint is reserved for the residual React-specific checks Biome does not provide. The plugin itself uses native ESM and keeps the familiar react/* rule namespace.

From 102 rules to 11

At the fork point, the upstream plugin exported 104 rule modules, with its all preset enabling 102 active rules. The author re-reviewed every rule and kept only those enforcing React 19 correctness or genuinely useful React-specific performance warnings.

Exactly 20 rules were dropped because Biome already produces the same diagnostic, including jsx-key, no-danger, no-unknown-property and self-closing-comp. Style and team-policy rules such as jsx-sort-props and function-component-definition were removed, as were heuristics like no-unused-prop-types and no-unused-state, which the author judged unable to answer project-wide questions from a local AST.

Only four original rule IDs survived: jsx-no-constructed-context-values, no-deprecated, no-direct-mutation-state and no-invalid-html-attribute. Around them the author added or narrowed seven more, among them no-function-default-props, which catches an API React 19 ignores, prefer-use-state-lazy-initialization, which warns about avoidable render-time work, and jsx-no-key-after-spread. One proposed rule forbidding components that render undefined was implemented and then deleted, because React 19 permits an undefined return and forbidding it would be team convention dressed up as a framework requirement.

Version 8.0.0 ships 11 rules, all in the recommended preset: nine correctness rules report errors and two performance rules report warnings. There is no separate all preset, since it would either duplicate recommended or differ only in severity.

Failures only real projects find

Unit tests and package checks were green by the third release candidate, but installing the plugin in two real applications surfaced the problems that mattered.

The no-invalid-html-attribute rule initially rejected valid attributes such as alt, accept, name, loading, form and value on elements like select, option and textarea. The fixes arrived in three rounds and ended with WHATWG HTML content attributes being separated from React DOM properties, instead of treating one metadata source as the whole contract.

The second failure involved Next.js. According to the author, eslint-config-next@16 builds flat config but still reads rules from a legacy-shaped react.configs.recommended.rules field, so a package exposing only react.configs.flat.recommended failed during configuration before ESLint could lint a file. A later release added the read-compatible field, and the author documented a Yarn resolution needed because Next.js imports the plugin under the unscoped eslint-plugin-react name.

The release process now checks the packed npm archive with publint, loads it from ESM, CommonJS and TypeScript consumers, exercises the supported Next.js configuration shape, and runs CI across all three supported Node.js lines.

Why it matters

The author frames the whole effort as a consequence of agent-driven development: the more autonomy coding agents are given, the more of a repository's expectations must be executable as pass or fail results that an agent can act on, rather than failures first discovered in manual review. Linting is one of those guardrails, alongside pre-commit hooks, tests and small reviewable commits.

For teams upgrading to ESLint 10 now, the plugin offers a working path for React 19 linting while the upstream fix remains unmerged. Its aggressive rule triage also illustrates a broader shift: with fast general-purpose linters like Biome covering breadth, framework plugins can shrink to the narrow checks where they still add real information.