[dayongkr]

Follow-up to #1957, which was merged before this came up in review.

Why

#1957 replaced Array.from(array) with the toArray helper to skip a copy when the input is already an array. toArray returns arrays unchanged, so the search now runs Array.prototype.lastIndexOf on the original — and the native method skips holes, where Array.from had been filling them with undefined:

const sparse = [1];
sparse[2] = 1;

lastIndexOf(sparse, undefined, 2);
// lodash: 1   before #1957: 1   after #1957: -1

lodash never converts the input at all — baseLastIndexOf walks backwards by index, so array[i] reads a hole as undefined and the question never arises.

What changed

Walk backwards by index instead of delegating to the native method. This matches lodash, and still avoids the copy for array-likes, which is what #1957 was after. The NaN branch already looped this way — it just fell through to the native call when it found nothing, so it now returns -1 directly.

Results

• Correctness: 18/18 cases match lodash, including dense arrays, fromIndex edges (negative, fractional, Infinity, null, true), NaN, array-like objects, and strings
• Performance: 1.15x faster than lodash on the existing suite (135.80 hz vs 118.10 hz)
• Bundle size: 681 → 658 bytes, since the toArray import goes away
• compat suite: 2,884 tests pass

Tests

Holes had no coverage, which is why the regression slipped through. Added: searching a sparse array for undefined, for a value (with and without fromIndex), and for NaN; plus array-like inputs (an object with length, and a string).

Sparse arrays are built as const a = [1]; a[2] = 1; rather than [1, , 1] so no lint suppression is needed.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
es-toolkit	Ready	Preview	Jul 30, 2026 1:34pm

[Antoliny0919]

This was a task I was supposed to take care of, so thanks for filling in the gaps, @dayongkr !

I hadn’t considered Array.from from the perspective of filling sparse slots.
I’ve been working on migrating to toArray recently, so I’ll keep cases like this in mind as well 😉

[dayongkr]

@Antoliny0919 Probably Array.from was used without that specific intent, and the behavior just happened to match. lodash doesn't seem to have deliberately intended it either, so it's an easy detail to miss. Thanks as always for contributing!