React analysis

Check React components with rules that match their renderer and the dependency state you are proposing.

Check IDs: reactCorrectness and reactAccessibility. Verified against the Zedbee 0.1.0 source snapshot on September 7, 2026.

Two separate checks

Correct React is not the same as accessible DOM

reactCorrectness checks React, Hooks, and JSX correctness with the managed React and Hooks plugins. reactAccessibility applies static JSX accessibility rules to browser-rendered React workspaces.

Both checks are enabled at error severity in fast, recommended, and thorough, with timing set to relevant. Enabled does not mean applicable to every project: Swarm first identifies the workspace’s environment.

The managed engines are ESLint 9.39.5, eslint-plugin-react 7.37.5, eslint-plugin-react-hooks 7.1.1, and eslint-plugin-jsx-a11y 6.10.2. These plugin versions are separate from the React version used to calibrate version-sensitive rules.

Swarm uses its own managed configuration, not your project’s ESLint, Babel, parser, or plugin configuration. It compares isolated baseline and target results and attributes findings to the selected change.

How findings are connected to your change

npx zedbee checks
npx zedbee scan --format json > zedbee-report.json

Applicability

Apply browser rules only to browser projects

JSX syntax alone does not establish that a workspace renders to the DOM. Swarm uses the environments discovered from project inspection to select the checks.

React checks by discovered workspace
Workspace environment	React correctness	DOM accessibility	Why
React without a discovered DOM renderer	Applicable	Not applicable	React alone does not imply browser output.
React DOM	Applicable	Applicable	The workspace uses browser-rendered React.
Ink, without a DOM environment	Applicable	Not applicable	Terminal components should not receive browser-DOM advice.
Next.js or Remix	Applicable	Applicable	Both are recognized React DOM environments.
JSX without a recognized React environment	Not applicable	Not applicable	Syntax alone is not enough to select these checks.

Selection is per workspace, so a monorepo can contain packages with different applicable checks. If a check appears inapplicable unexpectedly, inspect the selected manifest and the targets reported by zedbee checks before changing severity.

React version calibration

Use each snapshot’s own dependency state

For React correctness, Swarm chooses version settings independently for every workspace in the baseline and target snapshots. A React upgrade can therefore be analyzed with different settings on each side.

It starts with the workspace’s direct react declaration in the selected package.json. When that declaration is resolvable, a matching lockfile can provide a more precise version.

How React version settings are chosen
Available evidence	Version setting used
Resolvable direct React declaration and one unambiguous matching direct lockfile version	The matching locked version. A workspace-specific importer takes precedence; a broader record is considered only when its lockfile owns the workspace.
Resolvable declaration, but no usable unambiguous matching lockfile record	The manifest-derived version. For a supported range, Swarm uses its minimum supported stable version.
Missing, unsupported, or unresolvable direct React declaration	The managed React 19.2.0 fallback.

Supported snapshot lockfiles include package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, and text bun.lock. If a supporting lockfile cannot be parsed, React calibration silently falls back to the resolvable manifest version. You do not need to edit a lockfile just to satisfy React calibration. The separate vulnerability check may still report that lockfile as incomplete.

The fallback does not install or upgrade React. It supplies deterministic settings to version-sensitive rules. Swarm does not use the React plugin’s detect mode, load the project’s installed React package, or execute project React code to determine that setting.

Rules of Hooks, missing list keys, and DOM accessibility rules do not depend on this React version setting.

Review supported lockfile formats

Managed policy

Configure the check that owns the rule

Each check supports severity, timing, and a rules object for its bundled rule inventory. React and Hooks rules belong under reactCorrectness; jsx-a11y rules belong under reactAccessibility.

The example makes selected rules explicit. These checks already run with their managed recommended rules under the recommended profile; the example is not required to turn them on.

Unknown rules, rules belonging to another check, and custom plugins are rejected. Supported rule options follow the analyzer versions pinned by your installed Zedbee release. File-scoped overrides can tailor supported rules where needed.

Keep settings in the repository-root .zedbeerc.jsonc. Stage edits for local scans; commit and push them for CI runs that check out the updated commit. Use zedbee checks to inspect the effective policy and overrides.

When settings updates take effect

{
  "schemaVersion": 1,
  "profile": "recommended",
  "checks": {
    "reactCorrectness": {
      "severity": "error",
      "rules": {
        "react/jsx-key": "error",
        "react-hooks/rules-of-hooks": "error"
      }
    },
    "reactAccessibility": {
      "severity": "error",
      "rules": {
        "jsx-a11y/alt-text": "error"
      }
    }
  }
}

Practical examples

Review the behavior behind the finding

The list example illustrates react/jsx-key: an element created by a list mapping needs a key. Use a stable item identity appropriate to the data rather than adding a value solely to silence the rule.

The image example illustrates jsx-a11y/alt-text in a DOM workspace. The right text depends on the image’s purpose and context. A passing static check cannot decide whether a description is useful to someone using the page.

These examples show individual rules, not a complete inventory. A finding can be newly attributable even when an analyzer inspects more than the changed lines; review its location and attribution evidence along with the rule message.

Static JSX checks do not prove accessibility.

Test keyboard interaction, focus behavior, and assistive-technology use in the running interface. Passing these rules is not a substitute for checking the experience people actually use.

const items = [{ id: "a", name: "Ada" }];

// Missing key
const rows = items.map((item) => (
  <li>{item.name}</li>
));

// Stable identity from the item
const keyedRows = items.map((item) => (
  <li key={item.id}>{item.name}</li>
));

Fix and verify

Apply only the fixes Swarm can support

zedbee fix reactCorrectness limits the plan to supported React correctness fixes. It can include warning and blocking candidates, but only exact reported official fixes from the bundled React and Hooks rules. Suggestions and findings without an official fix remain manual.

React DOM accessibility does not support managed fixes. zedbee fix reactAccessibility is rejected rather than silently applying another kind of fix. Choosing good keys, descriptions, and interaction behavior can require decisions the analyzer cannot make for you.

Approved fixes change working files, never the Git index. Non-overlapping unstaged edits are preserved; conflicting exact fixes are skipped. Review the resulting diff, stage what you intend to keep, and rescan. The React-only selector does not opt into whole-file Prettier formatting.

For REACT_CORRECTNESS_ANALYSIS_FAILED or REACT_ACCESSIBILITY_ANALYSIS_FAILED, inspect the reported source file and diagnostic. Verify that its syntax is supported, and report a compatibility issue if valid project syntax cannot be analyzed. Exit code 2 is incomplete required analysis, not a clean result.

Review managed-fix boundaries

npx zedbee fix reactCorrectness
git diff
git add --patch
npx zedbee scan