emadadly/laravel-uuid
A lightweight Laravel package that adds UUID support to Eloquent models. Use the HasUuid trait to automatically generate UUIDs on model creation, as an extra column or primary key, with configurable column names and minimal setup.
Version 1.3.6 is a compatibility release — the only change is Laravel 12 support. That tells you two things up front: the package is actively maintained, and it has now caught up with the current framework major. There is no new API surface to learn, so your first step is not reading changelogs but confirming your own constraints line up.
composer.json will now reflect that. If you are still on Laravel 10/11, stay on the previous patch line until you plan the framework jump — the package itself is not forcing your hand.composer.json under extra.laravel.providers, it tells you what binds, singletons, facades, and config merges you get for free versus what needs manual wiring.php artisan vendor:publish --provider="Vendor\\Package\\PackageServiceProvider" --tag=config (adjust the tag — check the provider's publishes() call). The config file is usually the fastest way to understand the package's mental model: what it talks to, what it caches, what it authenticates against.Because 1.3.6 is a patch bump, an existing integration should keep working untouched. Treat the upgrade as a composer update plus a test run, not a migration project.
Dependency-inject, don't resolve from the container inline. Laravel 12's container is unchanged, so the idiomatic pattern still wins: type-hint the package's main class or contract in a constructor or controller method and let the container resolve it. This keeps your code testable and means a future breaking change to the class name is a one-line fix rather than a search-and-replace.
Wrap the package behind your own thin service. Even for a small package, put a App\Services\... class between your application code and the package's API. Day-to-day this pays off when you need to fake, cache, or add retry logic — and it makes the next major bump a contained problem.
Use the facade only at the edges. If the package ships a facade, it is convenient in Blade, jobs, and Artisan commands. In domain code, prefer the injected instance. Facades hide dependencies and make it easy to accidentally couple business logic to a package you may swap later.
Lean on the package's publishable assets at deploy time. Config and migration publishing should happen once, committed to your repo, and then version-controlled. Re-publishing on every deploy silently overwrites your tuned config — a classic way to lose an afternoon.
Queue and schedule integrations. Most Laravel packages expose work that is safe to defer. If the package's operations are I/O-bound, dispatch them as jobs with ShouldQueue and give them explicit $timeout and $tries. This is the single biggest day-to-day performance lever and it costs nothing to adopt early.
Test with the real container. In feature tests, let the package resolve normally against your phpunit.xml env rather than mocking it. Reserve $this->mock(...) for the boundaries — HTTP clients, mail, queues — that the package itself depends on. Laravel 12's Http::fake() and Queue::fake() mean you rarely need to stub the package directly.
Pin your constraint deliberately. Since 1.3.6 is the first Laravel 12-compatible release in this line, use a constraint like ^1.3.6 rather than ^1.3. It protects you from landing on an older patch that predates framework 12 support when resolving in a fresh install.
Patch version, real compatibility meaning. The version number says "non-breaking," and for your application code that is accurate. But the release does change what the package can run against. If your composer.json allows laravel/framework: ^10.0|^11.0 and Composer resolves the package to 1.3.6, you may get a package that expects PHP 8.2 and framework 12 conventions. Always read resolution output, not just the package version.
Watch the transitive PHP requirement. Laravel 12's PHP 8.2 floor propagates to every dependency that supports it. If your CI matrix still runs 8.1, it will fail on composer install before any of your tests execute. Bump the matrix in the same PR.
Service provider not discovered. If bindings are missing after an upgrade, run php artisan package:discover and then php artisan optimize:clear. Cached package manifests in bootstrap/cache/ are the most common source of "it worked locally" reports.
Config caching swallows env() calls. Any package config that calls env() directly will return null once php artisan config:cache runs. If a value behaves differently in production than locally, this is almost always why. Either keep the value in config/ or use the package's own env-backed config properly.
Facade alias collisions. Laravel 12 keeps the same alias registration behavior, but if the package registers a short alias that collides with your own facade, you get confusing resolution order. Check config/app.php's aliases and the provider's $aliases before assuming the package is broken.
Debugging the package itself. php artisan about gives you the environment at a glance. For anything deeper, Log::debug() around the call site beats reading source. If you must step in, php artisan vendor:publish the config (not the source) and set a verbose/debug flag if the package offers one.
Extension points to prefer. Published config first, then the package's events, then its contracts/interfaces for swapping implementations, and only then subclassing. Subclassing internal classes is the fastest route to pain at the next minor release, since those are not covered by semver promises.
Upgrade hygiene. Pin to ^1.3.6, run the suite, and check composer why-not if anything refuses to resolve. If you are not yet on Laravel 12, hold the previous patch and revisit together with your framework upgrade — there is no functional gain in 1.3.6 on its own.
How can I help you explore Laravel packages today?