feat(linter): Implement react/no-react-children rule.

[connorshea]

AI Disclosure: I used Claude Code for the implementation of the rule's run and is_imported_from_react functions. All other code (diagnostics, tests, rule docs, etc.) were written by me.

Fixes #20015. Part of #1022, I guess?

This rule is based on the following rules from @eslint-react/eslint-plugin:

• @eslint-react/no-children-count
• @eslint-react/no-children-for-each
• @eslint-react/no-children-map
• @eslint-react/no-children-only
• @eslint-react/no-children-to-array

The goal of the rule is to prevent all usage of React.Children, which is discouraged by the React docs.

Examples of rule violations:

import { Children } from 'react';

Children.toArray(children);
Children.map(children, child => <div>{child}</div>);
Children.only(children);
Children.count(children);
Children.forEach(children, (child, index) => {});

// ---

import React from 'react';

React.Children.toArray(children);

A few things to note, in terms of what this rule intentionally does not catch right now:

1. This rule will not catch CommonJS imports like const { Children } = require('react');. It didn't really seem worth the trouble.

2. This does not catch alias imports like import { Children as ReactChildren } from 'react';. I considered adding that case, but it would make the rule more complex for an edge case, and I wasn't sure that was really worthwhile. The original rule(s) from @eslint-react/eslint-plugin also didn't handle this.

3. There are a few other ways to get around this, like destructuring from React after importing it:

import React from 'react';
const { Children } = React;

I don't know that that is worth protecting against? We can always add support for complex cases like that in subsequent PRs if desired.

I tried to keep it as simple as possible, which means there will be some holes like the above, but it will be much easier to review and validate as a result, and the above patterns are generally uncommon anyway.

---

ecosystem-ci run, no new failures (not that any are even really possible, given this isn't a default rule / doesn't have a fixer): https://github.com/oxc-project/oxc-ecosystem-ci/actions/runs/22804771151

For validation purposes, it does add 7 new errors to the bsky results, before:

Found 0 warnings and 76795 errors.
Finished in 1.5s on 1555 files with 629 rules using 4 threads.

after:

Found 0 warnings and 76802 errors.
Finished in 1.4s on 1555 files with 630 rules using 4 threads.

Running the rule on the bsky codebase, all 7 results are correctly-detected violations:

oxlint results with this rule

  × eslint-plugin-react(no-react-children): `React.Children` should not be used.
    ╭─[src/view/com/pager/Pager.web.tsx:90:8]
 89 │       })}
 90 │       {Children.map(children, (child, i) => (
    ·        ────────────
 91 │         <View
    ╰────
  help: `React.Children` is uncommon and leads to fragile React components.
  note: https://react.dev/reference/react/Children#alternatives

  × eslint-plugin-react(no-react-children): `React.Children` should not be used.
    ╭─[src/components/FocusScope/index.tsx:52:12]
 51 │   const decoratedChildren = useMemo(() => {
 52 │     return Children.toArray(children).map((node, i) => {
    ·            ────────────────
 53 │       if (i === 0 && isValidElement(node)) {
    ╰────
  help: `React.Children` is uncommon and leads to fragile React components.
  note: https://react.dev/reference/react/Children#alternatives

  × eslint-plugin-react(no-react-children): `React.Children` should not be used.
    ╭─[src/components/forms/InputGroup.tsx:11:20]
 10 │   const t = useTheme()
 11 │   const children = React.Children.toArray(props.children)
    ·                    ──────────────────────
 12 │   const total = children.length
    ╰────
  help: `React.Children` is uncommon and leads to fragile React components.
  note: https://react.dev/reference/react/Children#alternatives

  × eslint-plugin-react(no-react-children): `React.Children` should not be used.
     ╭─[src/components/Tooltip/index.web.tsx:113:13]
 112 │ export function TextBubble({children}: {children: React.ReactNode}) {
 113 │   const c = Children.toArray(children)
     ·             ────────────────
 114 │   return (
     ╰────
  help: `React.Children` is uncommon and leads to fragile React components.
  note: https://react.dev/reference/react/Children#alternatives

  × eslint-plugin-react(no-react-children): `React.Children` should not be used.
     ╭─[src/components/Tooltip/index.tsx:455:13]
 454 │ export function TextBubble({children}: {children: React.ReactNode}) {
 455 │   const c = Children.toArray(children)
     ·             ────────────────
 456 │   return (
     ╰────
  help: `React.Children` is uncommon and leads to fragile React components.
  note: https://react.dev/reference/react/Children#alternatives

  × eslint-plugin-react(no-react-children): `React.Children` should not be used.
    ╭─[src/alf/typography.tsx:71:3]
 70 │   let hasEmoji = false
 71 │   Children.forEach(children, child => {
    ·   ────────────────
 72 │     if (typeof child === 'string' && createEmojiRegex().test(child)) {
    ╰────
  help: `React.Children` is uncommon and leads to fragile React components.
  note: https://react.dev/reference/react/Children#alternatives

  × eslint-plugin-react(no-react-children): `React.Children` should not be used.
    ╭─[src/alf/typography.tsx:87:10]
 86 │   }
 87 │   return Children.map(children, child => {
    ·          ────────────
 88 │     if (typeof child !== 'string') return child
    ╰────
  help: `React.Children` is uncommon and leads to fragile React components.
  note: https://react.dev/reference/react/Children#alternatives

Found 0 warnings and 7 errors.
Finished in 226ms on 1555 files with 1 rules using 8 threads.

[Copilot]

Pull request overview

This PR adds a new eslint-plugin-react rule (react/no-react-children) to warn on usage of the legacy React.Children API, aligning oxlint’s React guidance with React’s current recommendations.

Changes:

• Implement react/no-react-children rule logic, diagnostics, and unit tests with snapshot coverage.
• Register the rule in the react rules module and in generated rule dispatch/runner code.
• Add a snapshot file capturing expected diagnostics output.

Reviewed changes

Copilot reviewed 3 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
crates/oxc_linter/src/rules/react/no_react_children.rs	New rule implementation, documentation, and tests for detecting React.Children.* usage patterns.
crates/oxc_linter/src/rules.rs	Exposes the new rule module under the React rules namespace.
crates/oxc_linter/src/generated/rules_enum.rs	Adds the rule to the generated rule enum, IDs, and dispatch helpers.
crates/oxc_linter/src/generated/rule_runner_impls.rs	Registers AST node filtering/runner implementation for the new rule.
crates/oxc_linter/src/snapshots/react_no_react_children.snap	Snapshot of diagnostics emitted by the new rule’s tests.

[codspeed-hq]

Merging this PR will not alter performance

✅ 4 untouched benchmarks
⏩ 52 skipped benchmarks¹

---

_{Comparing no-child (6c3527b) with main (4ea8f9a)²}

Footnotes

1. 52 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (9a02606) during the generation of this report, so 4ea8f9a was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[Copilot]

Pull request overview

Copilot reviewed 3 out of 5 changed files in this pull request and generated no new comments.

[camc314]

Merge activity

• Mar 9, 6:08 PM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Mar 9, 6:08 PM UTC: camc314 added this pull request to the Graphite merge queue.
• Mar 9, 6:13 PM UTC: Merged by the Graphite merge queue.