Laravel Enum Collections Laravel Package

Getting Started

This release is a compatibility patch, so treat v3.4.2 as your floor when running on Laravel 13.

1. Require the package and confirm the resolved versions side by side:

   composer require <vendor>/<package>:^3.4
   composer show <vendor>/<package> laravel/framework
   

2. Check the constraint in composer.json. v3.4.2 exists specifically because Illuminate\Support\Collection::make() changed signature in Laravel 13.3, which means earlier 3.x releases will fatal on L13.3+ with an incompatible-declaration error. If you are pinned below 3.4.2, either upgrade the package or hold laravel/framework below 13.3.
3. Look first at the package's service provider and any class that extends or re-declares Collection. That is where the fix lands and where future framework drift will surface.
4. First use case: run one of your existing collection pipelines end-to-end (not just a unit test) on L13.3+ to confirm make() — and anything that calls it internally — behaves as expected.

Implementation Patterns

Pin deliberately in CI. Run a matrix of laravel/framework: ^12.0 and ^13.3 if you support both. The failure mode here is not a runtime exception you can catch — it's a PHP fatal at class-load time, so it only shows up when the class is autoloaded, which can hide from narrow unit tests.

Prefer composition over subclassing. If you are wiring this package's collection behaviour into your own code, avoid subclassing Collection or overriding make(). Use macros or Collection::macro() registration inside a service provider so framework signature changes cannot break your classes:

// app/Providers/AppServiceProvider.php
public function boot(): void
{
    Collection::macro('myTransform', fn () => $this->map(...));
}

Verify the resolved lock file in deploy. Because this is a patch-level fix to a signature incompatibility, a stale composer.lock on a server running a newer framework is the most likely production break. Add composer validate --strict and a composer show diff to your deploy checklist.

Assert container bindings if the package swaps the Collection instance. Some packages rebind Illuminate\Support\Collection; if yours does, check app(Collection::class) resolves to the expected class after the upgrade, and that queue workers / Octane are restarted so they don't hold the pre-upgrade class in memory.

Regression test the boundary. Add one test that constructs a collection via make() and one via collect(), since the two paths can diverge when a package overrides only one of them.

Gotchas and Tips

• Signature drift is silent until autoload. A Declaration of X::make(...) must be compatible with Illuminate\Support\Collection::make(...) error appears at class load, so php -l and static analysis will catch it faster than your test suite. Run vendor/bin/phpstan or php -d error_reporting=E_ALL artisan about after upgrading.
• "Fix" ≠ "feature." Do not treat v3.4.2 as a reason to refactor. It restores parity; behaviour should be identical to what you had on L12. If output changes, that's a bug worth reporting upstream.
• Check for other overridden methods. If make() broke, any other Collection method the package overrides is equally exposed to a future minor framework bump. Grep the package's vendor directory for extends Collection and read the method list.
• Octane and long-running workers cache classes in memory. Always php artisan octane:reload (or restart workers) after the composer update, otherwise you can run a mixed state where the old class definition persists.
• Cache clearing is usually irrelevant here but costs nothing: php artisan config:clear && composer dump-autoload -o resolves the majority of "it still fails after updating" reports.
• Report upstream fast if you support L13.0–13.2. The signature change is in 13.3; if you need to keep an older 13.x line, confirm with the maintainer whether a backwards-compatible shim is planned before pinning yourself into a corner.