no-fn-reference-in-iterator: Ignore locally declared functions?

I would like the following to be ignored by no-fn-reference-in-iterator:

const fn = item => {
  // do stuff with iterator items
};

iter1.forEach(fn);
iter2.forEach(fn);
iter3.forEach(fn);

Since fn is locally declared and defined the purpose of no-fn-reference-in-iterator does not apply. I see value in the following situations being reported:

const mapper = require('unicorn-mapper');

function doStuff(iter, fn) {
  iter.forEach(fn); // error on `fn` provided by argument
}

[2, 3, 4].forEach(mapper); // error as `mapper` is from a `require`

[fregante]

I’ve been disabling this rule as I go.

I get that it tries to prevent future breakage, but this exclusively depends on the function signature:

• does fn accept multiple arguments? Report it.
• the function signature cannot be verified? Report it.

That’s it.

Only node_modules introduce uncertainty because a future npm install might change the signature of fn after the lint, unless…

• there’s a lockfile which guarantees that fn won’t just change under your feet.

---

This means that single-parameter local functions (same file or other file) should not be reported by this check. If a local fn is changed to a multi-parameter, the lint will likely be run after this change and report it.

If lockfile detection can be part of a rule, node_modules can also follow the same logic.

[fregante]

Not always true that multiple arguments is a problem:

You’re right.

Changed my mind on this specific point:

- const showFruits = (name) => console.log(`I have many ${name}`)
+ const showFruits = (name, count = 1) => console.log(count `I have exactly ${count} ${name}`)

list.forEach(showFruits);

The problem is that (regardless of types) the linter does not know what the expected input of the function is. The second parameter could match the exact type and pass everywhere, yet still fall into the trap that this rule is meant to prevent.

If you follow this rule, you’d have written the loop this way and that diff wouldn’t have caused the issue:

- const showFruits = (name) => console.log(`I have many ${name}`)
+ const showFruits = (name, count = 1) => console.log(`I have exactly ${count} ${name}`)

list.forEach(fruit => showFruits(fruit));