Disable the unicorn/no-array-for-each rule

[leroykorterink]

There is a proposal to disable the unicorn/no-array-for-each rule.

unicorn/no-array-for-each: super annoying. introduces unnecessary verbosity
- @edgardz

[leroykorterink]

Benefits of for…of statement over the forEach method can include:

• Faster
• Better readability
• Ability to exit early with break or return

Additionally, using for…of has great benefits if you are using TypeScript, because it does not cause a function boundary to be crossed. This means that type-narrowing earlier on in the current scope will work properly while inside of the loop (without having to re-type-narrow). Furthermore, any mutated variables inside of the loop will picked up on for the purposes of determining if a variable is being used.

Please see the documentation of the rule.

[ThaNarie]

introduces unnecessary verbosity

I would only consider the array.entries() version, when needing the index, to be slightly more verbose.

const arr = [1, 2, 3, 4];

// same
arr.forEach(item => {
  console.log(item);
})
//vs
for (let item of arr) {
  console.log(item);
}

// slightly different
array.forEach((element, index) => {
  bar(element, index);
});
// vs
for (const [index, element] of array.entries()) {
  bar(element, index);
}

That small win is not enough for me to throw away all the benefits that for...of has over forEach.

You can even still write a forEach, eslint will automatically convert it for you :)

---

IMO the only valid use case (but feel free to add more) for forEach is when chaining after other array methods to do something with the created result:

// I prefer this
list
  .map(x => modifyX(x))
  .filter(x => x > 5)
  .forEach(x => executeX(x));

// but not this
[1, 2, 5].forEach((x) => executeX(x));

I'm not happy how eslint auto-fixes the first variant though :(

// horrible
for (const x of [1, 2, 5].map((x) => modifyX(x)).filter((x) => x > 5)) {
  executeX(x);
}

// much better
for (const x of [1, 2, 5]) {
  executeX(x);
}