prefer-find
Configuration
Enforce the use of Array.prototype.find() over Array.prototype.filter() followed by [0] when looking for a single result.
Rule Details
When searching for the first item in an array matching a condition, it may be tempting to use code like arr.filter(x => x > 0)[0]. However, it is simpler to use Array.prototype.find() instead, arr.find(x => x > 0), which also returns the first entry matching a condition. Because .find() only executes the callback until it finds a match, it is also more efficient.
The rule triggers on these patterns when the receiver's type is an array or tuple:
arr.filter(p)[0]arr.filter(p).at(0)arr.filter(p)['0']andarr.filter(p)[`0`]arr['filter'](p)[0]andarr[`filter`](p)[0]- Sequence and ternary wrappers:
(a, b, arr.filter(p))[0],(cond ? arr1.filter(p) : arr2.filter(p))[0] - Optional-chain receivers:
arr?.filter(p)[0]
It does not trigger when:
- The receiver type is not an array or tuple (e.g. a custom
Filterinterface,null,undefined). - The subscript or
.at(...)argument does not statically resolve to zero. - The
[0]access is itself optional (?.[0]), the.at(0)callee is optional (?.at(0)), or the.filter(...)call is optional (.filter?.(...)) — rewriting these would change short-circuiting semantics.
The rewrite is offered as a suggestion that you must explicitly apply — it is not auto-applied. .find() stops at the first match, but .filter() always visits every element, so if your .filter() callback has side effects, applying the suggestion will change behavior.
Examples of incorrect code for this rule:
Examples of correct code for this rule:
When Not To Use It
If you intentionally use patterns like .filter(callback)[0] to execute side effects in callback on all array elements, you will want to avoid this rule.