oxc-project/oxc · warning · OxcDiagnostic

Prefer `indexOf` over `findIndex` for simple equality checks

Error message

Prefer `indexOf` over `findIndex` for simple equality checks

What it means

Lint diagnostic from oxlint's `unicorn/prefer-array-index-of` rule. When the `findIndex`/`findLastIndex` callback only does a strict equality check against a value (`x => x === value`), it is exactly what `indexOf`/`lastIndexOf` already do, with less ceremony and typically faster engine-optimized code. The rule flags those simple callbacks and tells you to use `indexOf`.

Source

Thrown at crates/oxc_linter/src/rules/unicorn/prefer_array_index_of.rs:13

use oxc_ast::{
    AstKind,
    ast::{Expression, FormalParameter, Statement},
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::Span;
use oxc_syntax::operator::BinaryOperator;

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

fn prefer_array_index_of_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Prefer `indexOf` over `findIndex` for simple equality checks")
        .with_help("Use `indexOf(value)` instead of `findIndex(x => x === value)` for better clarity and performance")
        .with_label(span)
}

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

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Enforces using `indexOf` or `lastIndexOf` instead of `findIndex` or `findLastIndex`
    /// when the callback is a simple strict equality comparison.
    ///
    /// ### Why is this bad?
    ///
    /// Using `findIndex(x => x === value)` is unnecessarily verbose when `indexOf(value)`
    /// accomplishes the same thing more concisely and clearly. It also avoids the overhead
    /// of creating a callback function.

View on GitHub (pinned to e1e7af627c)

Solutions

1. Replace with `array.indexOf(target)` (or `lastIndexOf` for `findLastIndex`).
2. Run `oxlint --fix` to rewrite matches automatically.
3. Keep `findIndex` when the comparison is not strict equality or involves multiple values/properties; suppress inline if you intentionally keep it (e.g. for future predicate growth).
4. Disable the rule if the team standard is to always use `findIndex`/`findLastIndex` for symmetry.

Example fix

// before
const idx = ids.findIndex(id => id === selected);

// after
const idx = ids.indexOf(selected);

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

When it happens

Trigger: `array.findIndex(x => x === target)`, `array.findIndex(x => target === x)`, `array.findLastIndex(x => x === target)` — callbacks whose body is a single strict-equality (`===`) comparison using only the first parameter. Reported during oxlint runs on such CallExpressions.

Common situations: Developers who learned `findIndex` first and use it uniformly, or code migrated from `filter(x => x === v)[0]`-style rewrites. Also common in id-lookup code (`items.findIndex(i => i === selectedId)`). Appears when the unicorn category is enabled.

Related errors

• Prefer `find` over filtering and accessing the first result.
• 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/99b1a0a29035fd63. Report an issue: GitHub.