eslint-plugin-react

eslint-plugin-react is the standard ESLint plugin for React codebases, shipping over 100 rules that catch React-specific mistakes generic JavaScript linting can’t see — missing key props in lists, unsafe lifecycle method usage, incorrect Hooks naming, unused or undeclared prop-types, and dozens of JSX-formatting conventions. It plugs into both the legacy .eslintrc config system and ESLint 9’s flat config, with recommended, all, and jsx-runtime presets covering everything from a minimal safety net to every active rule enabled.

Maintained by the jsx-eslint organization since 2014, the plugin has grown alongside React itself, tracking class-component lifecycle deprecations, the Hooks API, and the React 17+ automatic JSX transform. Many rules ship autofixers or suggestion fixes, so eslint --fix can resolve issues like redundant closing tags or Hooks-naming inconsistencies without manual edits. It remains a near-universal devDependency for any team running ESLint against a React or JSX codebase.

What You Get

• Over 100 rules spanning JSX syntax, class-component lifecycle safety, Hooks conventions, and prop-types validation
• Both flat-config (configs.flat) and legacy .eslintrc config exports, so migration to ESLint 9 doesn’t require dropping the plugin
• Curated recommended and exhaustive all presets, plus a jsx-runtime preset for React 17+‘s automatic JSX transform
• Autofix (🔧) and suggestion (💡) support on many rules for one-command remediation via eslint --fix
• Shared react settings block (pragma, fragment, version detection, custom link/form component recognition) applied consistently across all rules
• Deprecated-rule tracking so teams can see which rules have been superseded without silently losing lint coverage

Common Use Cases

• Failing CI when a list render is missing a key prop, preventing subtle reconciliation bugs
• Extending jsx-runtime when migrating to React 17+‘s automatic JSX transform to stop flagging unnecessary React imports
• Enforcing prop-types/require-default-props discipline on JavaScript (non-TypeScript) component codebases
• Blocking no-unstable-nested-components to stop components being redefined inside a parent’s render body on every render
• Auditing Hooks usage with hook-use-state and related rules to keep useState destructuring and naming symmetric

Under The Hood

Architecture

The plugin has no orchestration engine of its own — ESLint’s own AST walker invokes each rule’s visitor callbacks. index.js aggregates the ~105 independent rule modules under lib/rules/ (one file per rule, each exporting standard ESLint meta + create(context)) and composes them into the recommended, all, jsx-runtime, and flat-config variants. The load-bearing internal abstraction is lib/util/Components.js, a shared component-detection utility (used alongside componentUtil.js, propTypes.js, and usedPropTypes.js) that many rules depend on to determine whether a given AST node is a React component and how its props/state are used; a change to that abstraction would ripple through a large share of the rule set.

Tech Stack

Plain CommonJS JavaScript with no runtime build step (TypeScript is used only to generate published .d.ts type declarations via build.tsconfig.json). Dependencies lean heavily on small ponyfill/polyfill packages (array-includes, object.entries, object.fromentries, es-iterator-helpers, string.prototype.matchall) to support the very wide engines: >=4 Node range, plus doctrine for JSDoc/proptype comment parsing, resolve and semver for module/version resolution, and jsx-ast-utils for JSX AST inspection. Dev tooling includes Mocha + Istanbul for tests, eslint-doc-generator to keep the README’s rule table in sync with rule metadata, and a GitHub Actions matrix testing across multiple Node versions and ESLint majors (3 through 9).

Code Quality

Test coverage is close to 1:1 — 104 test files under tests/lib/rules/ against roughly 105 rule modules — built on ESLint’s own RuleTester harness with explicit valid/invalid case tables, run against a matrix of parsers (babel-eslint, @typescript-eslint/parser across several major versions) to guard parser-specific regressions. CI enforces linting, a type-check pass via tsc, and a docs-generation check before tests run at all, and the project self-lints with eslint-plugin-eslint-plugin. Naming is consistent (kebab-case rule files matching rule IDs), and no swallowed-error patterns are evident — rules report through ESLint’s own context API rather than custom error handling.

API Design Adoption requires very little boilerplate: extending plugin:react/recommended gets a working baseline in two lines, and the shared settings.react block (pragma, fragment, version, link/form component recognition) is applied uniformly rather than repeated per-rule. Flat-config support was added without breaking the legacy .eslintrc surface, letting teams migrate on their own timeline, and the auto-generated per-rule docs table (via eslint-doc-generator) keeps rule metadata, fixability, and preset membership discoverable in one place.