oxlint-plugin-react-use-propswithchildren

An oxlint JS plugin that requires components that use children to type their props via React's own PropsWithChildren<Props> generic, and disallows declaring children explicitly as a field inside Props. This is the oxlint counterpart of eslint-plugin-react-use-propswithchildren, for projects that lint with oxlint instead of ESLint.

Rule

react-use-propswithchildren/require-props-with-children

Same three directions as the ESLint package's rule of the same name:

• Component uses children (destructured, or via props.children) but its props type isn't PropsWithChildren<Props> → missing PropsWithChildren.
• Props type declares children explicitly as its own field → always flagged.
• Props type is PropsWithChildren<Props> but children is never used → unnecessary.

Installation

npm install oxlint-plugin-react-use-propswithchildren --save-dev

Register it in .oxlintrc.json:

{
  "jsPlugins": [
    "./node_modules/oxlint-plugin-react-use-propswithchildren/index.js"
  ],
  "rules": {
    "react-use-propswithchildren/require-props-with-children": "error"
  }
}

Or copy .oxlintrc.json from this package as a starting point.

Compatibility

oxlint's JS plugin API (@oxlint/plugins' definePlugin/defineRule) is alpha and not covered by semver — expect breaking changes on oxlint upgrades. @oxlint/plugins and oxlint are versioned in lockstep (both tracked at the same ^1.x release here).

oxc parses .tsx natively and hands the JS plugin API a typescript-estree-compatible AST (same node names as @typescript-eslint), so utils.js here mirrors the ESLint package's AST-reading logic almost exactly — kept as a separate copy, not shared, since the two packages are published independently.

Limitations

Same as the ESLint package: a named type reference is resolved against local interface/type/PropsWithChildren<T> declarations in the same file; a type imported from elsewhere can't be resolved from a single file's AST, so the "explicit children in Props" check doesn't fire for it. oxlint's JS plugin API has no type-checker access at all (type-aware linting is native-Rust-only in oxlint), so there's no upgrade path for imported types here, unlike the ESLint package's optional type-aware mode.

children usage is detected as either a destructured { children } property, or a props.children member access when the parameter isn't destructured.

Local dev note: oxlint's native binding is an optional dependency (@oxlint/binding-darwin-arm64 etc.) that can fail to install due to a known npm bug (npm/cli#4828) even after a clean rm -rf node_modules package-lock.json && npm install — if oxlint --version throws "Cannot find native binding," install the platform package directly (e.g. npm install @oxlint/binding-darwin-arm64@<version> --save-optional).

Testing

npm test

Runs the local oxlint binary (--format=json) against the fixture in test/fixtures/ (test/run.js), asserting diagnostics land on exactly the expected lines.