Laravel Enum Collections Laravel Package

Product Decisions This Supports

• Framework upgrade planning (primary): v3.4.2 exists specifically to restore compatibility with Laravel v13.3's changed Collection::make definition. For any team with Laravel 13.3 on the roadmap, this release is the gate that determines whether the package can stay in the dependency list or must be patched, forked, or removed before the upgrade.
• Build vs. buy for collection-layer utilities: This package sits on top of / extends Illuminate\Support\Collection. The release is evidence for the classic trade-off — you get upstream compatibility work done for you, but you inherit a dependency on framework internals that can break on minor Laravel releases.
• Release/feature sequencing: Any in-flight feature that depends on custom collection behavior (data transforms, report builders, API resource shaping, pipeline-style processing) should be sequenced after this patch lands, not before.
• Dependency risk register: A patch release triggered by an upstream signature change is a concrete data point for the "framework coupling" risk entry — useful for quarterly dependency reviews and for deciding whether to pin, wrap, or isolate the package behind an internal abstraction.
• Support/maintenance evaluation: The speed of the fix is a signal about maintainer responsiveness. That feeds directly into the buy-vs-build decision and into whether to standardize on this package across teams.

When to Consider This Package

Consider adoption when:

• You are on Laravel and already extend or wrap Collection (custom collections, macros, pipeline helpers), and maintaining that yourself is not a differentiator.
• You are planning a Laravel 13.3 upgrade and need a dependency that keeps pace with framework internals rather than pinning you to an older minor.
• The package's surface area is small enough relative to your codebase that a future break is a contained fix, not a rewrite.
• You want a maintained implementation rather than an internal fork that nobody owns.

Look elsewhere — or wrap/fork — when:

• You require a stable public API across Laravel majors and cannot absorb patch-level churn from upstream signature changes.
• Native Collection methods already cover the use case; adding a dependency for thin sugar is not worth the coupling.
• You need vendor SLA, security review, or long-term support commitments that a small package cannot provide.
• Your platform is not on the Laravel versions the package tracks, or you are deliberately holding an older Laravel minor.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost utility dependency in the Laravel layer, and its latest patch (v3.4.2) is a compatibility fix for a change in Laravel 13.3. In plain terms: the maintainer is actively keeping it in step with the framework, which is what you want from a dependency of this kind. The decision it unlocks is whether we proceed with the Laravel 13.3 upgrade on schedule. Risk is low and contained — the package's footprint is narrow, and the worst case is a small patch or a local fork, not an architectural change.

For engineering: v3.4.2 fixes a break caused by Laravel v13.3 changing the Collection::make method definition. We should treat this as a maintenance patch, not a feature release: no new capabilities, no deprecations, no API changes on our side. Recommended actions: pin to ^3.4.2 in composer.json, run the upgrade branch against it before merging, and add a smoke test that exercises the collection path so the next upstream signature change fails loudly in CI rather than in production. Longer term, if we find ourselves patching this package more than once a year, that is the trigger to wrap it behind an internal interface or replace it with native Collection usage.