DEV Community

Cover image for More Agent Autonomy Needs Stronger Guardrails: React 19 Linting on ESLint 10
Vladimir Iglovikov
Vladimir Iglovikov

Posted on

More Agent Autonomy Needs Stronger Guardrails: React 19 Linting on ESLint 10

#eslint #react #open #opensource

The more autonomy I give coding agents, the more of a repository's expectations need to be executable. I do not want manual review to be the first place a predictable failure is discovered.

My projects now have more pre-commit hooks, tests, deterministic checks for project conventions, and small reviewable commits. The checks turn expectations into pass/fail results an agent can act on; the commits keep failures narrow enough to diagnose.

Linting is one of those guardrails. This story began when the React linting layer I relied on broke during an ESLint 10 upgrade.

I maintain several React applications and wanted to upgrade them to ESLint 10. The upgrade stopped at eslint-plugin-react.

ESLint 10 removed deprecated rule-context APIs. The current eslint-plugin-react@7.37.5 release declares support only through ESLint 9 and can crash under ESLint 10 with:

TypeError: contextOrFilename.getFilename is not a function
Enter fullscreen mode Exit fullscreen mode

The upstream compatibility issue was opened on February 7, 2026. As of August 23, it is still open more than six months later. The pull request, opened on July 30, is also still open.

That led me to release @ternaus/eslint-plugin-react: an independent React 19 continuation for ESLint 10.

Who this is for

The package has a deliberately narrow support matrix:

Tool Supported version
React 19+
ESLint 10
Biome 2.5.8+
Node.js 22.13, 24, or 26
ESLint config Flat config

React 18, ESLint 9, and .eslintrc* are outside the package contract.

My setup

My projects use Biome as the primary formatter and linter. Biome handles general JavaScript, TypeScript, JSX, DOM, and most React checks.

ESLint remains for checks that Biome does not provide, including framework plugins and several React 19 contracts.

The setup came from real Next.js and React codebases behind Albumentations.ai, sportscategory.info, and my-roots.me:

  • Next.js 16
  • React 19
  • TypeScript
  • ESLint 10 with flat config
  • Biome with the all preset
  • Yarn 4
  • Node.js 22, 24, and 26

My projects need a smaller rule set: the React-specific checks that still add information after Biome has finished.

What I inherited

I started from the upstream repository while preserving its Git history, MIT license, and attribution. The project is now maintained independently.

At the commit where the fork began, the upstream plugin exported 104 rule modules. Its all preset enabled 102 active rules; the other two were deprecated. The recommended preset named 22 rules, although one of them, react/no-unsafe, was explicitly disabled, so it enforced 21.

Carrying all of that forward would have preserved the package size without preserving a clear purpose. My target was narrower: React 19 checks that still add information after Biome has run.

How 102 active rules became 11

I reviewed the rules by the kind of decision they enforce:

Group Decision
Same diagnostic already available in Biome Remove from this plugin
Formatting, naming, file layout, or team policy Leave to Biome or the application
Broad heuristics that need project-wide or type-aware evidence Remove rather than report uncertain results
React 18, classic config, parser workarounds, or obsolete React APIs Remove from the React 19 contract
React 19 correctness or a useful React-specific performance warning Keep or implement

The first group accounted for exactly 20 rules, including jsx-key, no-danger, no-unknown-property, and self-closing-comp. The upstream rule support policy records the complete one-to-one mapping to Biome.

Rules such as jsx-sort-props, function-component-definition, and prefer-stateless-function were removed because they express style or team policy, not React 19 correctness. Rules such as no-unused-prop-types and no-unused-state were removed because a local AST heuristic cannot reliably answer a project-wide question. The remaining exclusions were legacy compatibility surface outside the package's stated support matrix.

Four original rule IDs survived that review: jsx-no-constructed-context-values, no-deprecated, no-direct-mutation-state, and no-invalid-html-attribute.

What I added

Among the upstream proposals relevant to this React 19 cutover, I evaluated three rule ideas that were still unmerged:

I initially implemented all three. I then removed no-render-return-undefined: React 19 permits an undefined return, so forbidding it would be a team convention presented as a framework requirement. The other two became no-function-default-props and prefer-use-state-lazy-initialization. The first catches an API React 19 ignores; the second is a warning for avoidable render-time work.

I also added or narrowed five rules around concrete React 19 behavior: controlled-form-requires-handler, jsx-no-key-after-spread, no-implicit-ref-callback-return, no-misspelled-lifecycle-methods, and no-prop-types.

That left 11 rules in version 8.0.0. All 11 are in recommended: nine correctness rules are errors, while the two performance rules are warnings. A separate all preset would either duplicate recommended or differ only by severity, so the package does not expose one.

The corner cases appeared in real projects

By 8.0.0-rc.3, the unit tests and package checks were green. Then I installed the plugin in Rooted and Albumentations.ai. That is where the useful failures started.

The first class of failures was HTML attribute metadata. no-invalid-html-attribute rejected valid attributes such as alt, accept, name, loading, form, and value on <select>, <option>, and <textarea>. The fixes arrived in three rounds: issue #21 and PR #22, then issue #25 and PR #26, and finally issue #29 and PR #31. The final fix separated WHATWG HTML content attributes from React DOM properties instead of treating one metadata source as the whole contract.

The second failure came from Next.js. eslint-config-next@16 builds flat config, but it still reads rules from the legacy-shaped react.configs.recommended.rules field. My package exposed only react.configs.flat.recommended, so configuration failed before ESLint could lint a file. Issue #24 and PR #27 added that read-compatible field without bringing .eslintrc support back into scope. I also documented the Yarn resolution needed because Next.js imports the plugin under the unscoped eslint-plugin-react name.

Those integrations produced release candidates 4, 5, and 6. They also changed the test strategy: the final release checks the packed npm archive with publint, loads it from ESM, CommonJS, and TypeScript consumers, and exercises the supported Next.js configuration shape. CI covers Node.js 22.13, 24, and 26.

The resulting package uses native ESM, ESLint flat config, and the familiar react/* rule namespace.

How to use it

The examples below use Yarn 4.

Install Biome, ESLint 10, and the plugin:

yarn add --dev @biomejs/biome@'>=2.5.8' eslint@^10 @ternaus/eslint-plugin-react@^8.0.0
Enter fullscreen mode Exit fullscreen mode

Enable Biome's full stable rule set and React domain:

{
  "linter": {
    "domains": {
      "react": "all"
    },
    "rules": {
      "preset": "all"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Then add the residual React rules to eslint.config.js:

import react from '@ternaus/eslint-plugin-react';

export default [
  {
    files: ['**/*.{js,jsx,mjs,cjs,ts,tsx}'],
    ...react.configs.flat.recommended,
  },
];
Enter fullscreen mode Exit fullscreen mode

If the glob includes TypeScript, configure a parser that supports TypeScript earlier in the flat config.

Run both tools:

yarn biome check .
yarn eslint .
Enter fullscreen mode Exit fullscreen mode

Rule IDs remain under the react namespace:

{
  rules: {
    'react/no-deprecated': 'error',
    'react/no-implicit-ref-callback-return': 'error',
  },
}
Enter fullscreen mode Exit fullscreen mode

Using it with Next.js

eslint-config-next imports the package under the unscoped name eslint-plugin-react. With Yarn, map that dependency to the maintained package:

{
  "devDependencies": {
    "@ternaus/eslint-plugin-react": "8.0.0"
  },
  "resolutions": {
    "eslint-plugin-react": "npm:@ternaus/eslint-plugin-react@8.0.0"
  }
}
Enter fullscreen mode Exit fullscreen mode

Keep both versions synchronized. This prevents eslint-config-next from installing the ESLint 9-only package alongside the ESLint 10 continuation.

Because Next.js registers it under react, existing react/* rule IDs continue to work.

When not to use it

This package does not cover every rule in the original plugin.

If your configuration depends on rules such as react/jsx-sort-props, react/display-name, or react/prop-types, check the complete rule catalog before migrating.

The package also has no React Native-specific compatibility contract. DOM rules only analyze proven lowercase HTML elements.

Links

Top comments (1)

Collapse
 
101beardo profile image
Tarun Sharma •

Dropping no-render-return-undefined instead of keeping it was the right call, a rule enforcing a team convention through the linter dressed up as a framework requirement is exactly the kind of thing that erodes trust in the rest of the ruleset once someone notices. The Yarn resolutions mapping for the unscoped eslint-plugin-react name is a nice trick, does npm's overrides field or pnpm's pnpm.overrides handle that redirect the same way, or did you only end up testing this on Yarn 4 projects