Rule Profile

interface CardProps {
  title: string;
  subtitle: string;
}

function Card(props: CardProps) {
  return <div>{props.title}</div>;
}

False Positive Pattern

The false positives now covered by this branch fall into two narrow families. The first is decorator-based indirect prop usage: a React prop is not read inside the component body, but is consumed by typed decorator machinery through a callback whose first parameter is the component props object. The second is an upstream typing mismatch: in React.Component<Props, State, Snapshot> declarations, react/no-unused-prop-types can treat the State or Snapshot declaration as if it were a props contract and report its members as unused props.

function DecoratorFactoryComponent(props: DecoratorFactoryProps) {
  return <div />;
}

track((props: DecoratorFactoryProps) => ({
  context_module: props.contextModule,
  user_id: props.userId,
}))(DecoratorFactoryComponent);

interface AnchorState {
  activeLink: null | string;
}
interface AnchorProps {
  href?: string;
}
interface AnchorSnapshot {
  scrollTop: number;
}

class Anchor extends React.Component<AnchorProps, AnchorState, AnchorSnapshot> {
  render() {
    const { activeLink } = this.state;
    return <a href={this.props.href}>{activeLink}</a>;
  }
}

False Negative Risk

The risk is bounded by reporting by default unless TypeScript proves that the decorator callback's first parameter has the same declared props type as the component, and by suppressing non-props generic reports only when the reported declaration is proven to belong to a React class state/snapshot slot rather than a real props contract. This avoids suppressing unrelated metadata callbacks and avoids hiding legitimate reports when the same declaration is also used as props elsewhere.

interface SharedType {
  unused: string;
}
interface Snapshot {
  scrollTop: number;
}

class PropsOwner extends React.Component<SharedType> {
  render() {
    return <div />;
  }
}

class StateOwner extends React.Component<{}, SharedType, Snapshot> {
  render() {
    return <div>{this.state.unused}</div>;
  }
}

Fix Summary

The fix adds two focused S6767 suppressions: one for indirect prop usage through typed decorator callbacks, and one for upstream reports on React class non-props generics. It resolves the component binding used at the decorator site, matches callback parameter types against the component props type, and separately classifies reported type declarations as props vs state/snapshot before suppressing.

• Reuses shared React helper logic for component binding lookup, including named function expressions, plus TypeScript declaration matching for non-props generic detection.
• Recognizes direct member reads and whole typed-props forwarding in decorator callbacks, while keeping unrelated metadata callbacks reportable by default.
• Adds valid and invalid regression tests around decorator shapes, third-generic state/snapshot misreports, and mixed props/non-props reuse boundaries.

Ruling Report

Code no longer flagged (21 issues)

S6767

ant-design/components/input/ClearableLabeledInput.tsx:32

    30 |   disabled?: boolean;
    31 |   direction?: DirectionType;
>   32 |   focused?: boolean;
    33 |   readOnly?: boolean;
    34 |   bordered: boolean;

ant-design/components/input/ClearableLabeledInput.tsx:40

    38 | /** This props only for input. */
    39 | export interface ClearableInputProps extends BasicProps {
>   40 |   size?: SizeType;
    41 |   suffix?: React.ReactNode;
    42 |   prefix?: React.ReactNode;

ant-design/components/input/ClearableLabeledInput.tsx:42

    40 |   size?: SizeType;
    41 |   suffix?: React.ReactNode;
>   42 |   prefix?: React.ReactNode;
    43 |   addonBefore?: React.ReactNode;
    44 |   addonAfter?: React.ReactNode;

ant-design/components/input/ClearableLabeledInput.tsx:43

    41 |   suffix?: React.ReactNode;
    42 |   prefix?: React.ReactNode;
>   43 |   addonBefore?: React.ReactNode;
    44 |   addonAfter?: React.ReactNode;
    45 |   triggerFocus?: () => void;

ant-design/components/input/ClearableLabeledInput.tsx:44

    42 |   prefix?: React.ReactNode;
    43 |   addonBefore?: React.ReactNode;
>   44 |   addonAfter?: React.ReactNode;
    45 |   triggerFocus?: () => void;
    46 |   status?: InputStatus;

ant-design/components/input/ClearableLabeledInput.tsx:45

    43 |   addonBefore?: React.ReactNode;
    44 |   addonAfter?: React.ReactNode;
>   45 |   triggerFocus?: () => void;
    46 |   status?: InputStatus;
    47 | }

desktop/app/src/ui/app-menu/app-menu.tsx:41

    39 |    * menu will receive focus.
    40 |    */
>   41 |   readonly openedWithAccessKey: boolean
    42 | 
    43 |   /**

desktop/app/src/ui/branches/branch-list.tsx:30

    28 |    * See IBranchesState.defaultBranch
    29 |    */
>   30 |   readonly defaultBranch: Branch | null
    31 | 
    32 |   /**

desktop/app/src/ui/branches/branch-list.tsx:35

    33 |    * The currently checked out branch or null if HEAD is detached
    34 |    */
>   35 |   readonly currentBranch: Branch | null
    36 | 
    37 |   /**

desktop/app/src/ui/branches/branch-list.tsx:45

    43 |    * See IBranchesState.recentBranches
    44 |    */
>   45 |   readonly recentBranches: ReadonlyArray<Branch>
    46 | 
    47 |   /**

...and 11 more

New issues flagged (2 issues)

S6767

eigen/src/app/Scenes/Artwork/Components/CommercialInformation.tsx:34

    32 |   me: CommercialInformation_me$data
    33 |   hasStarted?: boolean
>   34 |   tracking?: TrackingProp
    35 |   biddingEndAt?: string
    36 |   hasBeenExtended?: boolean

eigen/src/app/Scenes/Artwork/Components/CommercialInformation.tsx:37

    35 |   biddingEndAt?: string
    36 |   hasBeenExtended?: boolean
>   37 |   refetchArtwork: () => void
    38 |   setAuctionTimerState?: (auctionTimerState: string) => void
    39 | }

Summary

This PR adds five targeted false-positive suppressions to rule S6767 (unused prop types) to handle indirect prop consumption patterns that the upstream react/no-unused-prop-types rule doesn't fully recognize.

The new escape hatches:

1. React class non-props generic declarations (State, Snapshot) that upstream misclassifies as unused props
2. Typed decorator callbacks that consume props indirectly (both factory and annotation forms)
3. Whole-props handoff through helper functions or spread operators
4. Props forwarding to custom (non-React) superclasses in component constructors
5. Props consumed in forwardRef callbacks (already existed, now clarified)

Scope: The fixes are narrowly scoped — decorator callbacks must have TypeScript-verified props types matching the component, and React class non-props reports are only suppressed when a third generic parameter is present. This keeps legitimate unused-prop reports visible while eliminating false positives observed in real projects (ant-design, desktop, eigen, etc.).

Impact: Test expectations across multiple projects show dozens of false-positive suppressions, confirming these patterns are widely used in production TypeScript React code.

What reviewers should know

Start here: Read decorator.ts to see the five escape hatches and their decision tree in shouldSuppressUnusedPropType() (lines 113–154).

Key implementation details:

• decorator-indirect-prop-usage.ts is the largest addition — handles both @decorator(callback) and decoratorFactory(...)(Component) patterns, with type verification via isSameDeclaredPropsType() (line 175)
• react-non-props-usage.ts leverages TypeScript's type checker to distinguish State/Snapshot from Props in class declarations — only suppresses when the reported type is truly non-props (line 107)
• whole-props-usage.ts is shared logic now reused by decorator callbacks (line 26 import) to detect buildPayload(props) and spread patterns
• New helpers are isolated per escape hatch with minimal cross-file dependencies

Non-obvious decisions:

• Decorator callbacks use caching (WeakMap by component node) to avoid repeated type checks — see react-non-props-usage.ts lines 43–48
• The decorator callback must introduce its own props parameter (not close over the original) to need special handling — see comment at lines 167–171 in decorator-indirect-prop-usage.ts
• Generic type equality (with any, unknown, nested generics) is handled by areSameTypeDeclarations() in the type helper

Testing: Unit tests show edge cases like generic aliases, named function expressions, method signatures, and literal-keyed properties — all now correctly handled.

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

There is still a gap in the decorator-factory suppression for named function expressions.

getComponentIdentifier() currently prefers the inner self-name of a FunctionExpression / ClassExpression over the outer variable binding:

const WrappedComponent = function InnerWrappedComponent(props: Props) {
  return <div>{props.label}</div>;
};

But hasDecoratorFactoryCallPropUsage() needs to follow the binding that is actually used at the decorator application site:

track((props: Props) => ({
  context_module: props.contextModule,
}))(WrappedComponent);

In this shape, the relevant reference is WrappedComponent, not InnerWrappedComponent, so the current implementation misses the decorator application and still reports contextModule as unused.

I reproduced this locally after npm ci + npm run bbf with a small RuleTester case, and it still fails with one unusedPropType error.

Please adjust the component-variable lookup to follow the outer binding for named expressions here, and add a regression test for that case. A good fit would be a new valid case in packages/analysis/src/jsts/rules/S6767/unit.typescript.test.ts like:

declare const React: any;
declare function track<P>(
  mapper: (props: P) => Record<string, unknown>,
): <TComponent>(target: TComponent) => TComponent;
interface NamedExpressionProps {
  label: string;
  contextModule: string;
}
const WrappedComponent = function InnerWrappedComponent(props: NamedExpressionProps) {
  return <div>{props.label}</div>;
};
track((props: NamedExpressionProps) => ({
  context_module: props.contextModule,
}))(WrappedComponent);

I think there is still a scope gap against JS-1394.

The original ticket is explicitly about props consumed through decorator annotations (@track(...) / @screenTrack(...) on the component), and the Jira discussion later treated decorator and decorator-factory forms as the same FP family. The current branch only implements the curried wrapper shape in hasDecoratorFactoryCallPropUsage(); I don't see corresponding support for class decorator annotations via node.decorators.

Could you extend the remediation to also cover the annotation form, for example:

@track((props: Props) => ({
  context_module: props.contextModule,
  user_id: props.userId,
}))
class MyTrackedComponent extends React.Component<Props> {
  render() {
    return <div />;
  }
}

As it stands, the branch fixes only one syntactic manifestation of the ticket's FP pattern.

The new decorator callback suppression still looks too broad.

hasDecoratorFactoryCallPropUsage() / isPropsCallbackUsingProp() currently treat any first-parameter callback passed through decorate(...)(Component) as if that parameter were the component props. That means a shape like this is now suppressed even though the prop is still genuinely unused:

function decorate(metadataMapper) {
  return function applyDecorator(target) {
    return target;
  };
}
function DecoratedComponent(props) {
  return <div />;
}
DecoratedComponent.propTypes = {
  contextModule: PropTypes.string,
};
decorate(function (metadata) {
  return {
    context_module: metadata.contextModule,
  };
})(DecoratedComponent);

I reproduced that locally with NoTypeCheckingRuleTester: expected 1 unusedPropType error, got 0.

So the current remediation is still suppression-first: unknown decorator callback APIs are assumed to be props mappers based only on a property-name coincidence. Because isPropsCallbackUsingProp() is shared, the same risk also applies to the annotation path when upstream still reports.

Can we tighten this back to a report-first shape and add an invalid regression test for this boundary? If we cannot prove that the callback parameter is actually the component props, we should report by default rather than suppress.

While validating the non-props escape, I found a false negative on wrapped props contracts.

A class such as React.Component<Readonly<SharedType>, SharedType, Snapshot> could be misclassified as non-props because the props slot wraps the same declaration instead of exposing it as the exact same enclosing type. That incorrectly suppressed a real unused-prop report.

Fixed in 18c4a287d3ebcb98746a33a93e5df7da7887f689 by making the non-props escape check whether the relevant React type slot exposes the reported member, rather than relying only on exact enclosing-type declaration equality when a reported member is available.

Quality Gate passed

Issues
0 New issues
3 Fixed issues
0 Accepted issues

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

See analysis details on SonarQube

Clarification on the latest Sonar Review summary:

• The areSameTypeArguments / Box<any> point is already fixed on current HEAD. areSameTypeArguments() now handles any / unknown before the symbol-based branch, so identical instantiations like Box<any> no longer fall into the old recursive false path.
• The getComponentIdentifier() point is not a current correctness issue. That helper is only called for actual component nodes, and the VariableDeclarator fallback is the intended path for variable-assigned components such as const Foo = () => ..., const Foo = function () {}, and const Foo = class extends React.Component {}. It is not used to derive identifiers from arbitrary declarators like const label = "hello".

So there is no remaining blocker from that review body on the current branch.