feat(collections/unstable): accept Iterable in interleave

[tomas-zijdemans]

interleave now widens the API to Iterable without extra cost for array callers. This is in line with the general direction of the collections module. interleave is very close to zip that does not support Iterable, but looking at the module as a whole, I think it's zip that needs to change.

Also added a two-array fast path (no inner loop, no per-pair bounds check) and a branch for equal-length inputs where the length guard is unnecessary. This should help with two very common use cases. The general unequal-length path is unchanged.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.43%. Comparing base (a3a6ef6) to head (b8269fb).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7088   +/-   ##
=======================================
  Coverage   94.43%   94.43%           
=======================================
  Files         630      630           
  Lines       50566    50584   +18     
  Branches     8969     8975    +6     
=======================================
+ Hits        47750    47768   +18     
  Misses       2247     2247           
  Partials      569      569           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bartlomieju]

Widening from ReadonlyArray to Iterable is a nice improvement. A few concerns:

The two-array fast path has subtle ordering differences for unequal-length inputs

The general path interleaves in round-robin order: it picks one from each array per round, skipping exhausted arrays. The two-array fast path emits all remaining elements from a first, then all remaining from b. For equal-length inputs these are equivalent, but for unequal-length inputs the behavior differs from the general path.

Example with 3+ arrays (general path): interleave([1,2,3], ["a"], [true, false]) produces [1, "a", true, 2, false, 3] — continuing round-robin after "a" is exhausted.

With the two-array fast path: interleave([1,2,3], ["a"]) would produce [1, "a", 2, 3] — same result as general path here since there are only two arrays. Actually on closer inspection, for two arrays the tail elements only come from one side, so it matches. This is fine.

Missing test coverage for the fast paths

The new tests only cover iterables (Set, generator). There are no tests specifically exercising:

• The two-array fast path with unequal lengths (to verify it matches general-path semantics)
• The equal-length fast path with 3+ arrays

These fast paths should have explicit tests confirming identical output to the general path.

Array.isArray check vs Array.from for all inputs

The approach is sensible — avoid copying arrays that are already arrays. One edge case: a subclass of Array would pass Array.isArray but might have overridden iteration behavior. This is extremely unlikely in practice, just noting it.

[tomas-zijdemans]

Agree with all points. Here is what I changed:

• Added test for two-array fast path
• Added tests for 3+ equal-length arrays
• Added JSDoc note about eager consumption
• Dropped the equal-length fast path

[bartlomieju]

The Iterable widening looks good — clean API improvement. Two minor items:

minLength is computed for all calls but only used by the two-array fast path

Move it inside the if (arrayCount === 2) block (or just compute it there as Math.min(a.length, b.length)). No need to track it for 3+ inputs.

Missing test: first array shorter than second

The "handles second array longer" test has [1, 2, 3], ["a"] (first is longer). Add a test with the first array shorter, e.g. interleave([1], ["a", "b", "c"]) → [1, "a", "b", "c"], to exercise the second tail loop in the fast path.

[tomas-zijdemans]

Good catch. I dropped minLength from the shared loop and now compute it inline when needed.

For the test "first array shorter than second" is already available. See line 30 in the test file ☺️