What causes "Prefer `.some(…)` over non-zero length check from `.filter(…)`." in oxc-project/oxc?

Replace `arr.filter(fn).length > 0` with `arr.some(fn)` (and `.length === 0` with `.every(x => !fn(x))` or `!arr.some(fn)`).

oxc-project/oxc · warning · OxcDiagnostic

Prefer `.some(…)` over non-zero length check from `.filter(…

Error message

Prefer `.some(…)` over non-zero length check from `.filter(…)`.

What it means

Lint diagnostic from oxlint's `unicorn/prefer-array-some` rule (variant `non_zero_filter`). `filter(fn).length > 0` (or `!== 0`, `> 0`) builds an entire filtered array just to test whether anything matched. `some(fn)` expresses existence directly, short-circuits at the first match, and allocates nothing. This message fires on the non-zero length check over a `filter` result.

Source

Thrown at crates/oxc_linter/src/rules/unicorn/prefer_array_some.rs:23

use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};
use oxc_syntax::operator::BinaryOperator;

use crate::{
    AstNode,
    ast_util::{call_expr_method_callee_info, is_method_call, outermost_paren_parent},
    context::LintContext,
    rule::Rule,
    utils::is_boolean_node,
};

fn over_method(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Prefer `.some(…)` over `.find(…)` or `.findLast(…)`.").with_label(span)
}

fn non_zero_filter(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Prefer `.some(…)` over non-zero length check from `.filter(…)`.")
        .with_label(span)
}

fn negative_one_or_zero_filter(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Prefer `.some(…)` over `.findIndex(…)` or `.findLastIndex(…)`.")
        .with_label(span)
}

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

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Prefers using [`Array#some()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/some) over [`Array#find()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/find), [`Array#findLast()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/findLast) with comparing to `undefined`,
    /// or [`Array#findIndex()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/findIndex), [`Array#findLastIndex()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/findLastIndex)
    /// and a non-zero length check on the result of [`Array#filter()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/filter)
    ///

View on GitHub (pinned to e1e7af627c)

Solutions

Replace `arr.filter(fn).length > 0` with `arr.some(fn)` (and `.length === 0` with `.every(x => !fn(x))` or `!arr.some(fn)`).
Run `oxlint --fix` to convert matched patterns automatically.
Keep `filter` when the filtered array is used afterwards; if only sometimes, hoist `const matches = arr.filter(fn);` and check `matches.length` — suppress the line if still flagged.
Disable the rule if the codebase intentionally prefers filter-length chains.

Example fix

// before
const hasFatal = errors.filter(e => e.fatal).length > 0;

// after
const hasFatal = errors.some(e => e.fatal);

Defensive patterns

Strategy: validation

Validate before calling

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

Prevention

Write `arr.some(fn)` instead of `arr.filter(fn).length > 0` by habit — it short-circuits and allocates nothing.
In review, treat filter-length-in-boolean-context as a blocking nit; it is both slower and less readable.

When it happens

Trigger: Patterns like `errors.filter(isFatal).length > 0`, `if (list.filter(x => x.active).length !== 0)`, truthiness on `filter(...).length`. Detected as a `filter` call whose `.length` participates in a non-zero comparison (via `call_expr_method_callee_info` and boolean-context analysis in the rule).

Common situations: One of the most common anti-patterns in review feedback; appears when teams enable the unicorn category or migrate from ESLint unicorn. Especially costly on hot paths with large arrays, since filter always runs to completion.

Related errors

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