crates/biome_js_analyze/tests/specs/nursery/useArraySome/invalid.js (1)

1-21: Good coverage of core patterns.

You might also consider adding a reversed-operand case (e.g. 0 < items.filter(x => x > 1).length or -1 !== items.findIndex(x => x > 1)) since detect_find_index_comparison_pattern already handles both sides — would be nice to have a snapshot proving it works.

crates/biome_js_analyze/src/lint/nursery/use_array_some.rs (4)

61-65: Consider wiring type Options = UseArraySomeOptions instead of ().

The UseArraySomeOptions struct exists in biome_rule_options but isn't referenced here. The codegen typically expects type Options = UseArraySomeOptions even when the struct is empty — keeps things consistent and future-proof if options are added later.

---

43-43: Consider .inspired() instead of .same() for the source mapping.

The original prefer-array-some covers additional patterns (e.g. filter(...).length in boolean context without a comparison, indexOf → includes inside .some()). Since this implementation is a subset, .inspired() is the more accurate qualifier.

Based on learnings: "For rules derived from other linters, use the sources metadata with RuleSource::Eslint and either .same() for identical behavior or .inspired() for different behavior/options."

---

158-188: detect_filter_length_pattern only matches when the .length is on the left side of the comparison.

Patterns like 0 < items.filter(x => x > 1).length won't be caught because left_is_expression is only checked against left. The detect_find_index_comparison_pattern already handles both sides — worth considering parity here.

Not a bug (the rule simply won't fire for reversed operands), but it's an asymmetry worth noting.

---

285-304: The is_number_literal_value(&expression, -1.0) check on line 287 is likely dead code.

JS parsers don't produce negative number literals; -1 is always a unary minus applied to 1. The unary-expression path below (lines 291–303) is the one that does the real work. The initial check is harmless but could be misleading.

crates/biome_js_analyze/src/lint/nursery/use_array_some.rs (4)

158-188: detect_filter_length_pattern only matches when the length expression is on the left-hand side.

Reversed comparisons such as 0 < arr.filter(fn).length or 0 !== arr.filter(fn).length are silently ignored because:

1. Line 168 unconditionally requires the left operand to be the .length expression.
2. Operators like LessThan are absent from the match on line 174.

Contrast with detect_find_index_comparison_pattern, which already handles both operand positions. Parity here would be nice.

Sketch of a more symmetric approach

     let left = comparison.left().ok()?;
+    let right = comparison.right().ok()?;
+    let operator = comparison.operator().ok()?;
+
+    let left_is_length = left_is_expression(&left, parent_member.syntax());
+    let right_is_length = left_is_expression(&right, parent_member.syntax());
+
-    if !left_is_expression(&left, parent_member.syntax()) {
-        return None;
-    }
-
-    let right = comparison.right().ok()?;
-    let operator = comparison.operator().ok()?;
-    let matches = match operator {
-        JsBinaryOperator::GreaterThan => is_number_literal_value(&right, 0.0),
-        JsBinaryOperator::GreaterThanOrEqual => is_number_literal_value(&right, 1.0),
-        JsBinaryOperator::StrictInequality | JsBinaryOperator::Inequality => {
-            is_number_literal_value(&right, 0.0)
-        }
-        _ => false,
-    };
+    let other = if left_is_length {
+        &right
+    } else if right_is_length {
+        &left
+    } else {
+        return None;
+    };
+
+    // Normalise: treat `0 < length` the same as `length > 0`, etc.
+    let normalised_op = if right_is_length { flip_operator(operator) } else { operator };
+
+    let matches = match normalised_op {
+        JsBinaryOperator::GreaterThan => is_number_literal_value(other, 0.0),
+        JsBinaryOperator::GreaterThanOrEqual => is_number_literal_value(other, 1.0),
+        JsBinaryOperator::StrictInequality | JsBinaryOperator::Inequality => {
+            is_number_literal_value(other, 0.0)
+        }
+        _ => false,
+    };

(You'd need a small flip_operator helper that maps > ↔ <, >= ↔ <=, and keeps !=/!== unchanged.)

---

190-220: Missing common findIndex patterns: >= 0 and > -1.

The unicorn rule also flags findIndex(...) >= 0 and findIndex(...) > -1 (and the reversed forms). These are arguably more common in the wild than !== -1. Worth adding for completeness — especially if the metadata claims .same() behaviour.

---

79-90: Logical-NOT context for find/findLast is not detected.

!arr.find(fn) is a common existence-check pattern that the upstream unicorn rule flags, but is_in_boolean_context only covers if/while/for/ternary test positions. A JsUnaryExpression with ! operator wrapping the call would slip through.

Not blocking — fine as a follow-up — but worth a tracking comment or TODO.

---

253-265: nearest_parent_binary_expression only traverses parenthesised expressions.

This is fine for the current patterns, but note it would silently fail for (arr.filter(fn)).length > 0 because the parent of the call node would be a JsParenthesizedExpression, not a JsStaticMemberExpression, so detect_filter_length_pattern would return None before this function is even reached. An edge case, but worth being aware of.