somnambulist/collection
A PHP/Laravel collection package that extends the standard Collection with type-safe wrappers, extra helper methods, and immutable-style operations for cleaner, more predictable data manipulation.
Architecture fit. somnambulist/collection is a dependency-free PHP collection abstraction with typed and (reportedly) mutable/immutable variants. The architectural fit question is not “is this well built?” but “where does it earn its place?” In a Laravel codebase, Illuminate\Support\Collection already ships as a first-class citizen — it is framework-coupled, universally known by Laravel developers, and battle-tested at scale. Adopting a second collection library inside a Laravel app creates a vocabulary split (two Collection types, two map/filter contracts) with no framework integration payoff. The package's defensible niche is framework-agnostic code: standalone SDKs, shared domain packages, CLI tools, or PHP services that must not depend on illuminate/support. If our work is Laravel-centric, this package is redundant; if we publish reusable libraries, a zero-dependency typed collection is a legitimate architectural asset.
Integration feasibility. Mechanically trivial: Composer install, PSR-4 autoloading, no transitive dependencies, MIT license. There is no service provider, no config, no facade — which is the point and also limits Laravel ergonomics (no auto-discovery, no container bindings out of the box). Integration risk is therefore low on effort and high on decision clarity — we must define where collection boundaries sit (internal utilities vs. public API types) before adoption, because once typed collections leak into public signatures they become expensive to swap.
Technical risk. Two distinct risk profiles. Code-level risk is low: small API surface, no dependency tree, MIT (forkable). Ecosystem-level risk is material: 11 stars, 0 dependents, a single-maintainer pattern typical of the somnambulist family, and a release cadence that (while recent — June 2024) reflects one person's availability. Supply-chain risk is near zero; abandonment and PHP-version-drift risk are the real exposures. A dormant dependency-free library is survivable but will silently age against new PHP runtimes and language features.
Key questions.
Illuminate\Support\Collection does not (typed element enforcement? true immutability? specific sorting/groupBy semantics)? If the answer is “nothing material,” reject for Laravel work.Stack fit. Poor-to-moderate for Laravel application code — redundant with Illuminate and adds cognitive load. Strong for standalone libraries and shared internal packages that must stay framework-free, and for teams that want explicit typed collections as part of a public contract. The decision should be scoped, not global: “we use this only in the acme/domain package,” never “we use this instead of Illuminate collections.”
Migration path. Because it is dependency-free and MIT, both adoption and exit are cheap — invert that into a deliberate strategy: adopt behind a thin internal adapter/interface (e.g., a CollectionFactory or domain-specific collection contract) so call sites do not import the vendor namespace directly. This makes swap-or-fork a one-file change. For existing Laravel code, do not migrate Illuminate collections — instead introduce somnambulist only where collections cross a framework boundary (e.g., data returned from a reusable package).
Compatibility. Confirm the Composer php constraint against our runtime matrix and CI, and audit the test suite across the PHP versions we support. There is no Laravel coupling to conflict with, but that also means no Illuminate helpers (collect(), Arr::) apply — teams must not mix semantics. Verify PSR-4 correctness and any ext-* requirements in composer.json before committing.
Sequencing.
Illuminate to quantify differentiation.Maintenance. Expect to effectively self-maintain. Low churn is a double-edged sword: fewer breaking changes, but also slower PHP-version tracking and security triage. Assign a named internal owner, monitor upstream releases (June 2024 is current), and budget a small annual “dependency health” review. Because there are zero transitive dependencies, the maintenance surface is only the library itself — a genuine operational advantage.
Support. Community-only, no SLA, single-maintainer bus factor. Treat upstream as best-effort and our adapter as the support boundary: internal developers raise issues against the adapter, not the vendor. Document the fork contingency in the architecture decision record so the team knows the exit is planned, not improvised.
Scaling. Collections are in-memory; performance is typical O(n) per operation and memory-bound by dataset size. This is fine for request-scoped and moderate batch work, but it is not a streaming/DB-scale abstraction — do not use it where Illuminate lazy collections, generators, or chunked queries are appropriate. Benchmark only if a hot path is migrated; otherwise the framework's collection is equally fast.
Failure modes.
somnambulist and Illuminate collections, causing subtle semantic bugs (sort stability, key preservation, mutability). Mitigation: adapter + linting/static analysis rules.Ramp-up. Low. Collection semantics (map, filter, reduce, sort) are standard, and Laravel developers will recognize the idioms quickly — the risk is over-familiarity, not a learning curve. Budget a short internal note distinguishing the two collection types and when to use each. Ramp-up is measured in hours, not weeks; the real cost is governance (deciding where it belongs) rather than onboarding.
TPM recommendation. Do not adopt for Laravel application code — Illuminate\Support\Collection wins on integration, talent familiarity, and support. Consider somnambulist/collection only for framework-agnostic shared packages where a zero-dependency typed collection is a genuine architectural requirement, and only after the spike confirms differentiated capability, adopted behind an adapter with a documented fork contingency.
How can I help you explore Laravel packages today?