@DamienCassou, thanks for the bug report. The issue that you raised is very interesting.
The first thing that comes to my mind is that the rule is actually detecting something not adaptable in your code: as soon as we pass a function that accepts more than one parameter to setUpdateFn, the code would not behave as expected:
function main() {
let update = makeUpdate();
update("hello");
}
function makeUpdate() {
let updateFn = () => true;
fetchItems({
setUpdateFn: (fn) => (updateFn = fn),
});
return (...args) => updateFn(...args);
}
function fetchItems({setUpdateFn}) {
setUpdateFn((arg, others) => console.log(arg, others));
}
main()
When we execute this script, we see that hello undefined is logged to the console, which is expected since main always execute update() by passing it one single parameter, and we can’t do anything about that from outside main. Said differently, there is no point at passing to setUpdateFn a function that accepts less or more than one single parameter.
What this means is that updateFn is a function that accepts one parameter and that returns any, and the first assignment to it is not reflecting that: let updateFn = () => true;
I recommend that you update the first assignment to let updateFn = (arg) => true;. This would make the error disappear by explictely establishing the signature of updateFn.
Now, allow me to go a bit further: for no-extra-arguments to actually behave as you expect, it would require some code interpretation.
Let’s consider this code sample:
const main = (numberOfArguments, value) => {
let updateFn = () => {
console.log('No argument passed');
};
let updateFnWasChanged = false;
if (numberOfArguments) {
updateFn = (arg) => {
console.log(arg);
};
updateFnWasChanged = true;
}
if (updateFnWasChanged) {
updateFn(value);
}
else {
updateFn();
}
}
main(1, 'hello');
Today, the rule would raise at line 13. But in a perfect world, it would not raise at all because, if the execution flow enters in the if (updateFnWasChanged) { branch, it is guaranteed that updateFn is a function that actually accepts one argument. We know that by reading the code, but for a rule to actually understand that, it would need to interpret the code and keep track of the fact that if updateFnWasChanged is true, then updateFn is actually accepting one parameter.
Unfortunately, this is outside the current scope of the rule, which can only statically analyze the code. But this is a very exciting route to explore in the future.
Anyway, sorry for the long post. Let me know what you think.
Cheers,
Eric.