JS-1389 Fix FP in S6767: props reported unused when component wraps React.forwardRef

[sonar-nigel]

Fixes a false positive in rule S6767 where props are incorrectly reported as unused when an outer function component passes props via closure into a nested React.forwardRef() or forwardRef() callback.

Root Cause

The upstream no-unused-prop-types rule tracks prop usage per component scope boundary. It attributes props.label usage to the inner forwardRef scope rather than the outer component, causing false positives in the S6767 decorator.

Changes

• Extends the S6767 decorator with a forwardRefCalleePatterns array and a containsForwardRefCall helper
• After the existing hasPropsCall guard, adds a component-scoped check that suppresses the report when the owning component's subtree contains a forwardRef call
• Suppression requires a non-null componentNode, ensuring only the affected component is suppressed — sibling components with genuinely unused props are still reported
• Adds test cases covering: React.forwardRef closure pattern, bare forwardRef closure pattern, component-scoped suppression (sibling TP still fires), and TypeScript interface-based props with React.forwardRef
• No ruling file changes needed: the closure-into-forwardRef FP pattern does not appear in the ruling test corpus

Relates to JS-1389.

[github-actions]

Ruling Report

✅ No changes to ruling expected issues in this PR

[francois-mora-sonarsource]

The current suppression fires for the entire component as soon as any forwardRef call is found in its subtree, regardless of which specific prop was flagged. This can produce false negatives: a component that uses forwardRef internally but also has genuinely unused props declared in propTypes would have all its reports silenced.

A more precise approach: suppress only when the specific reported prop is actually referenced inside the forwardRef callback. Rather than walking the AST, use ESLint's scope analysis — it has already built the reference graph for all variables in the component:

1. Get the component's scope via context.sourceCode.getScope(componentNode)
2. Look up the props variable by name (componentNode.params[0] gives the parameter, whose .name is the props identifier)
3. Iterate variable.references — each gives the props Identifier node at a specific use site
4. For each reference, check whether its parent is a MemberExpression accessing the flagged prop name (non-computed), and whether that reference is lexically inside a forwardRef callback (walk up ancestors to confirm it sits inside the first argument of a matching forwardRef(...) call)

This way, props genuinely used via closure are suppressed, while props that are declared in propTypes but never referenced inside the callback are still reported. It also naturally handles renamed props parameters without hardcoding "props" as a string.

[sonar-nigel]

Good catch. The broad suppression was indeed a false-negative risk.

The fix replaces containsForwardRefCall with isPropReferencedInForwardRefCallback, which now:

1. Finds each forwardRef call in the component's subtree
2. Checks the first argument (the callback body) for a props.<propName> member expression matching the specific reported prop
3. Suppresses only if that prop name is actually referenced inside the callback — props that are genuinely unused pass through to context.report

The prop name is extracted from descriptor.data.name, which is what eslint-plugin-react sets when reporting no-unused-prop-types.

A new invalid test case was added to cover the scenario described in the comment: a component with React.forwardRef where label is used inside the callback (suppressed) but color is not (still reported).

[github-actions]

README Freshness Check

❌ The rules README is out of date.

A fix PR has been created: #6618

Please review and merge it into your branch.

[francois-mora-sonarsource]

The new hasPropMemberReference helper hardcodes 'props' as the parameter name — it will silently miss the FP when the outer component names its parameter differently (e.g. ownProps, p). It also re-traverses the component subtree on every reported prop, duplicating work ESLint has already done.

A more robust and efficient approach is to use ESLint's pre-built scope data instead:

1. Get the component's scope: context.sourceCode.getScope(componentNode)
2. Read the props parameter name from componentNode.params[0] (if it's an Identifier) — no hardcoded string
3. Look up the variable: scope.set.get(propsParamName)
4. Iterate variable.references — ESLint has already collected every props reference site; no traversal needed
5. For each reference, check whether its parent is a non-computed MemberExpression accessing propName, and whether it sits inside a forwardRef callback (short ancestor walk up to confirm)

This resolves both issues: the props parameter name is taken from the actual binding rather than assumed, and the reference list is O(1) to obtain since ESLint built it during its own traversal.

[sonar-review-alpha]

Conclusion: Solid fix. The scope-based reference walk is precise (suppresses only the specific reported prop, not all props), conservative (rejects destructured params and computed member accesses), and correctly bounded (ancestor walk only matches when the member access is nested inside a forwardRef call, not just anywhere in the component). The sentinel test that verifies the upstream rule still raises the FP is a particularly good safety net.

🗣️ Give feedback

[sonar-review-alpha]

LGTM! ✅

🗣️ Give feedback

[sonar-nigel]

Both issues have been addressed in the latest commit (Use scope references for forwardRef prop suppression).

The updated hasPropMemberReference implementation now:

1. Reads the actual parameter name from componentNode.params[0] (an Identifier node) — no hardcoded 'props' string
2. Calls sourceCode.getScope(componentNode).set.get(propsParam.name) to obtain the scope variable
3. Iterates variable.references directly — ESLint's pre-built reference list; no subtree re-traversal

The ancestor walk is now a short upward climb (isPropReferenceInForwardRefCallback walks parent nodes from the MemberExpression up to find the enclosing forwardRef call), not a downward subtree scan.

A test case with the renamed 'ownProps' parameter was also added to confirm the fix handles non-default prop parameter names correctly.

[sonar-nigel]

Thank you for the thorough review!

[sonar-nigel]

Thank you for the review!

[francois-mora-sonarsource]

LGTM - fixes S6767 false positives when outer function component props are accessed via closure inside a nested React.forwardRef() or forwardRef() callback — #6591

[sonar-nigel]

Thank you for the review and approval!

[sonar-nigel]

Good catch — the ancestor walk was finding any forwardRef CallExpression in the ancestry chain without verifying the reference sits inside its first argument specifically. I've updated isPropReferenceInForwardRefCallback to track the previous node as we walk up, and added call.arguments[0] === prev to the check. This ensures suppression only fires when the prop member access is lexically inside the render callback (arguments[0]), not in the callee position or a later argument.

Also fixed a stale comment in the TypeScript test that still referenced containsForwardRefCall (the old approach).

[sonar-nigel]

Thank you for the review!

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
90.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[sonar-review-alpha]

LGTM! ✅

🗣️ Give feedback

[sonar-nigel]

Thank you for the review!