oxc-project/oxc · warning · OxcDiagnostic

Prefer `find` over filtering and accessing the first result.

Error message

Prefer `find` over filtering and accessing the first result.

What it means

Lint diagnostic from oxlint's `unicorn/prefer-array-find` rule. Calling `.filter(predicate)` and then taking element `[0]` (or `.shift()`/`.pop()` for last) scans the whole array and allocates an intermediate array; `Array.prototype.find` / `findLast` stops at the first match. The rule flags the filter-then-index pattern and recommends `find`.

Source

Thrown at crates/oxc_linter/src/rules/unicorn/prefer_array_find.rs:18

use oxc_ast::{
    AstKind,
    ast::{
        Argument, AssignmentTarget, BindingPattern, CallExpression, Expression,
        SimpleAssignmentTarget, UnaryOperator,
    },
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};

use crate::{
    AstNode, ast_util::is_method_call, context::LintContext, rule::Rule,
    utils::call_expr_member_expr_property_span,
};

fn prefer_array_find_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Prefer `find` over filtering and accessing the first result.")
        .with_help("Use `find(predicate)` instead of `filter(predicate)[0]` or similar patterns.")
        .with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct PreferArrayFind;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Encourages using `Array.prototype.find` and `Array.prototype.findLast` instead of
    /// taking the first or last matching element from `filter(...)`.
    ///
    /// ### Why is this bad?
    ///
    /// Using `filter(...)[0]` or array destructuring to get the first match is less
    /// efficient and more verbose than using `find(...)`. `find` and `findLast`
    /// short-circuit when a match is found, whereas `filter` evaluates the entire array.

View on GitHub (pinned to e1e7af627c)

Solutions

1. Replace `arr.filter(fn)[0]` with `arr.find(fn)` and `arr.filter(fn).pop()` with `arr.findLast(fn)`.
2. Run `oxlint --fix` — the rule rewrites the chain automatically when the predicate is reusable.
3. Keep `filter` when you truly need ALL matches afterwards (not just the first); suppress the line if it is a deliberate pattern.
4. Disable via `"unicorn/prefer-array-find": "off"` if the team prefers explicit filter chains.

Example fix

// before
const admin = users.filter(u => u.role === 'admin')[0];

// after
const admin = users.find(u => u.role === 'admin');

// oxlint --fix --filter unicorn/prefer-array-find src/
// CI gate: oxlint --deny-warnings src/

When it happens

Trigger: Member-call chains like `users.filter(isAdmin)[0]`, `items.filter(x => x.active).shift()`, `logs.filter(severe).pop()` — i.e. `is_method_call` on `filter` followed by immediate element access. Reported during oxlint scans when the rule is on.

Common situations: Very common in older codebases written before ES2015 `find`, or by developers coming from languages without `find`. Also hits performance-sensitive paths where the array is large — the lint warning often coincides with a real O(n) waste. Appears in bulk when enabling the unicorn category.

Related errors

• Prefer `indexOf` over `findIndex` for simple equality checks
• Prefer Array#flat() over legacy techniques to flatten arrays
• `Array.flatMap` performs `Array.map` and `Array.flat` in one
• Prefer `.some(…)` over non-zero length check from `.filter(…
• Prefer `.some(…)` over `.find(…)` or `.findLast(…)`.

AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/721b4b6896ee3896. Report an issue: GitHub.