Simple Livewire Select Laravel Package

Getting Started

Minimal path from zero to first working call:

1. composer require <vendor>/<package> — v1.7.0 is the first release whose illuminate/* constraints include ^11.0, so on a Laravel 11 app this is the minimum version that will resolve. On Laravel 10 you can stay on 1.6.x if you have a reason to.
2. Look at three things in this order:
   • README.md for the intended happy path (this is the only source of truth for method names — don't infer the API from the provider).
   • composer.json → extra.laravel.providers / extra.laravel.aliases to confirm the package auto-registers. On Laravel 11 the auto-discovery mechanism is unchanged, so you should not need to touch bootstrap/providers.php.
   • The published config file (php artisan vendor:publish --tag=<package>-config) — read it before writing code; most "why doesn't this work" questions are answered by a default in there.
3. First use case: publish config, set any credentials/queue names in .env, then exercise one read-only operation in php artisan tinker before wiring it into a controller or job. If the tinker call works, the container bindings and config resolution are correct and any later failure is your code.

Because 1.7.0 is a Laravel-11-only-in-practice change (new framework support, no API surface change), an existing Laravel 10 integration should keep working untouched after the bump.

Implementation Patterns

Resolve from the container, not with new. The package's service provider binds its main class as a singleton in almost all cases. Type-hint it in constructors and let Laravel inject it; this is also what makes it swappable in tests.

Config over code. Prefer the published config for tenant IDs, queue connections, timeouts, and drivers. Values baked into your own wrapper classes are the usual cause of "works locally, breaks in staging."

Wrap it once. Put a thin application-level adapter (e.g. App\Services\...) in front of the package. Three benefits that pay off in day-to-day work: your call sites don't churn when the package's minor versions shift, you have one place to add logging/tracing, and tests can bind a fake to the adapter rather than to the vendor class.

Queue-heavy packages: if the package dispatches jobs or webhooks, check the config for a queue connection key and point it at a dedicated queue. Running package work on default alongside everything else is the most common source of slow-consumer incidents.

Testing pattern:

public function test_something(): void
{
    $this->app->bind(VendorInterface::class, fn () => new FakeClient());

    // or, if the package ships fakes:
    Vendor::fake();
    // ... exercise
    Vendor::assertSent(fn ($payload) => $payload->id === 1);
}

If the package has no fake, Http::fake() (for HTTP-based packages) or a container binding is the fallback. Isolate integration tests that hit the real service behind a group (--group=external) so CI stays fast.

Upgrade workflow for this release: bump the constraint, run composer update <vendor>/<package>, then php artisan config:clear && php artisan cache:clear before testing. Cached config from a Laravel 10 install is the number-one cause of phantom failures after a framework upgrade.

Gotchas and Tips

• Laravel 11 has no app/Http/Kernel.php or app/Console/Kernel.php. If you previously patched the package's behaviour by editing those files (adding global middleware, scheduling), that code now lives in bootstrap/app.php under ->withMiddleware() / ->withSchedule(). Anything copied from a pre-11 tutorial will silently not apply.
• Config files are no longer in the default skeleton. config/ may not exist in a fresh Laravel 11 app. Publishing a package config still works and still gets merged with the package's defaults, but don't write code that assumes config('myfile.key') exists before you've published — rely on the package's own default rather than a null check you forgot.
• Laravel 11 changed the default cache and session drivers to database. A package that assumes file or array semantics (lock behaviour, TTL, Cache::flush() scope) can behave differently. If the package uses the cache for locks, give it its own cache store in config rather than sharing default.
• Carbon 3 / nesbot/carbon differences ship with Laravel 11. Date maths around month-end and diffIn* sign handling changed in places; if the package does date bucketing, spot-check the boundaries.
• Version gating: if you're on Laravel 10 and run composer update, you'll stay on 1.6.x and get no security or bugfixes from 1.7+. If the package drops 10.x in a future release, this is your warning shot — plan the framework upgrade rather than pinning indefinitely.
• composer why-not <vendor>/<package> 1.7.0 is the fastest way to find the transitive constraint blocking the upgrade (usually laravel/framework or a dev tool like larastan).
• Extension points to prefer over vendor edits: published config, container bindings to interfaces the package resolves, macros/extend callbacks if the package documents them, and published views/translations. Never patch vendor/ — the fix will vanish on the next composer install, and on this release that's exactly the moment you'll be debugging something else.
• Debugging: if a facade or alias isn't resolving after upgrading, re-run composer dump-autoload — auto-discovery reads a cached manifest in bootstrap/cache/packages.php, which can go stale when composer.lock changes. Deleting that file forces a re-scan.
• Check the CHANGELOG for 1.6 → 1.7 even though this release note is one line. "Added framework support" releases occasionally also bump minimum PHP or drop a deprecated method; the release note summary is not the diff.