Fixed Array Functions Laravel Package

Product Decisions This Supports

• Feature feasibility for memory-sensitive paths. SplFixedArray stores data with far less per-element overhead than a standard PHP array, and this release brings the API to Laravel Collection parity (70+ methods). That removes the main historical objection — "we'd have to write our own helper methods" — and makes it viable to spec features over large numeric datasets (reporting tables, exports, batch aggregates) without provisioning more memory.
• Standardize vs. fragment. With sum(), avg(), min(), max(), partition(), pluck(), join(), and when()/unless(), teams can express aggregation and shaping logic in the same idiom they already use for Collections. As a PM this supports a single house style decision: Collection API for associative/dynamic data, this package for large fixed-shape numeric data — same vocabulary, lower cognitive load, fewer PR review debates.
• Build vs. buy. Prior to this release, the honest options were (a) accept Collection memory overhead, (b) hand-roll helpers, or (c) convert to arrays at the boundary. All three carry cost: infra spend, maintenance burden, or copy overhead. A maintained package with 290 tests, 100% coverage, PHPStan Level 9, and Laravel 13 support is now cheaper to adopt than to replicate — buy.
• Roadmap de-risking. The release is explicitly fully backward compatible with no breaking changes and no migration step. That means it can be scheduled as an opportunistic dependency bump inside an existing sprint rather than a roadmap line item — no upgrade project, no regression budget.
• Use cases worth prototyping: queue workers and scheduled jobs that aggregate large result sets (fewer OOM/timeouts), CSV/report generation pipelines, dashboard rollups, and partition-style validation passes ([$valid, $invalid]) over imported records.
• Operational signal. CONTRIBUTING.md, SECURITY.md, issue templates, and a PR checklist are maturity markers. They make the dependency defensible in a vendor/security review conversation and reduce "bus factor" objections — but they are documentation, not a guarantee. See the caveats below.

When to Consider This Package

Adopt when:

• You have numeric-indexed, fixed-size or append-once data in a hot path: large query results, import batches, report datasets, queue payloads.
• Memory ceiling or per-worker cost is a real constraint — the value proposition is footprint, not raw speed alone.
• Your team already thinks in Laravel Collections; the parity API means near-zero onboarding.
• You want the safety rails: 100% test coverage, PHPStan Level 9, semantic versioning with a documented no-breaking-change upgrade path, and Laravel 13 readiness for future framework upgrades.
• You need auditable dependency hygiene (SECURITY policy, structured disclosure) for a compliance or vendor review.

Look elsewhere — or stay on plain Collections — when:

• Your data is associative or keyed by strings, needs dot-notation access, or must grow and shrink dynamically. SplFixedArray is integer-indexed and fixed-capacity by design; this is a data-shape constraint, not a missing feature, and it will not be fixed by a future release.
• You depend on Collection surfaces not covered by parity — verify the specific methods you call (lazy collections, higher-order messaging, groupBy/keyBy style reshaping) against the method reference before committing. "70+ methods" is broad, not exhaustive; treat parity as a claim to spot-check, not assume.
• Your workload is small arrays (hundreds of elements). The memory win is negligible and the conversion ceremony adds noise for no benefit.
• You require a large, multi-vendor-backed dependency. This is effectively a single-maintainer project; governance docs reduce but do not eliminate continuity risk. If your org has a bus-factor policy for critical-path libraries, this likely fails it — acceptable for an internal reporting job, less so for core billing logic.
• The data crosses a boundary into libraries expecting native arrays frequently; conversion cost can erase the memory gain. Prototype with real payloads before standardizing.

How to Pitch It (Stakeholders)

For executives: This is a low-risk, zero-migration upgrade to an existing dependency that lets us process large datasets with a much smaller memory footprint. In practical terms that maps to fewer worker instances, fewer out-of-memory incidents in batch jobs, and faster report/export pipelines — capacity savings rather than new capability. The risk profile is unusually clean: no breaking changes, no rewrite, and the library ships with a strict static-analysis bar, full test coverage, and a published security policy. The main caveat to state plainly is that it only applies to large, uniformly-shaped numeric datasets, and it is a small open-source project with a single primary maintainer — so we should adopt it in non-critical paths first and keep it out of core transaction logic until we've validated it in production.

For engineering: Version 3.1.0 closes the parity gap with Laravel Collections — 23 new methods covering aggregation (sum, avg, min, max, reduce), conditionals (every, some, when, unless), and transformation (reject, partition, pluck, join, keys, values), plus tap/pipe for chain debugging. The filter() callback now receives $key as an optional second argument, matching Collection semantics, with no breakage to existing call sites. Performance work removed intermediate array allocations from filter() and the aggregate methods. Notably it also adds Laravel 13 support, so adopting now doesn't create a framework-upgrade blocker later. Upgrade is a composer update — no code changes required. Recommended path: pick one existing batch job or report generator with known memory pressure, benchmark it against the Collection implementation with production-shaped data, and let that result decide whether we extend adoption. Where it doesn't fit — associative arrays, dynamic sizing, string keys — keep using Collections; this is a complement to the Collection API, not a replacement for it.