enhancement(linter) expand only-used-in-recursion to support jsx

[camc314]

currently, only-used-in-recursion only supports cases such as:

function foo(arg0) {
    foo(arg0)
}

it could be expanded to support cases such as:

function Listitem({ depth }) {
    return <Listitem depth={depth + 1} />
}

cc @no-yan

[camc314]

i can't seem to assign this. But @no-yan is going to work on it!

[Boshen]

i can't seem to assign this. But @no-yan is going to work on it!

You can only assign an outside contributor when they make a comment here.

[no-yan]

It would have been better to comment here. Thanks for the reminder!

@camc314

1. Why does the only-used-in-recursion rule only apply fixes when the argument is at the end of the function? Is it to avoid issues with residual arguments?
2. The only edge case I can think of is when using the spread operator in JSX attributes. Do you have any other potential edge cases in mind?

For example, in this case, the spread operator might alter the program’s behavior, which is why no fix is applied:

function Test(props) { // could be {key: 0}
    return (
        <Test key={2} {...props} />
    );
}

But in most cases, like the one below, removing an argument seems safe in JSX:

- <Item innerItem={item} width={width} />
+ <Item width={width} />

[camc314]

Why does the only-used-in-recursion rule only apply fixes when the argument is at the end of the function? Is it to avoid issues with residual arguments?
i think i did it this way because if you remove args that are not the last one, you've got to also find everywhere the fn is used and remove those args also to retain the same behaviour. Feel to skip a fixer for this one
The only edge case I can think of is when using the spread operator in JSX attributes. Do you have any other potential edge cases in mind?

i think reporting the spread should be fine. i can't think of any other edges.

function Test(props) { // could be {key: 0}
    return (
        <Test key={2} {...props} />
    );
}

reporting here should be fine right? i don't think key: 0 can ever be in the props

From the react docs

Note that your components won’t receive key as a prop. It’s only used as a hint by React itself. If your component needs an ID, you have to pass it as a separate prop: .

[no-yan]

Thanks for the clarification!

reporting here should be fine right? i don't think key: 0 can ever be in the props

(This might be off-topic)
You're right that it doesn't end up in the props, but it does end up in the key.
The jsx implementation prioritizes element.props.key (e.g. <Component {...{key:0}}) over element.key (e.g., key={2}).
So, if we remove this props, it could unintentionally cause the key to change.