Amqp Rabbit Manager Laravel Package

Getting Started

v2.12.0 is a compatibility-focused release, so the first thing to do is check your Laravel version before touching the package.

1. Verify framework compatibility. The package now requires Laravel ^11.0. If your application is still on Laravel 10, do not upgrade — pin to the 2.11.x line until you've moved the app to Laravel 11+.
2. Install/upgrade:

   composer require vendor/package:^2.12 --with-all-dependencies
   

   Use --with-all-dependencies so transitive illuminate/* constraints are recalculated rather than left pinned from the previous install.
3. Confirm discovery and publishables. Auto-discovery should register the service provider, but run the publish command so you have the config file in source control:

   php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"
   

   If the package ships migrations, run php artisan migrate after publishing.
4. First use case. The fastest confidence check is to hit the package's primary entry point from a tinker session or a throwaway route — configure credentials/options in config/package.php (or the corresponding env vars), resolve the service from the container, and confirm it returns a real result before wiring it into application code.

Where to look first when something is off: config/package.php (published copy wins over the vendor default), the service provider's register()/boot() for bindings and extension hooks, and php artisan about to confirm the package version actually loaded.

Implementation Patterns

Pin the framework, not just the package. The release explicitly supports Laravel 11, 12, and 13. Keep your root composer.json on laravel/framework: ^11.0 and let the package float within ^2.12; hard-pinning illuminate/support to an exact minor is the most common cause of resolver conflicts on the next upgrade.

Upgrade workflow for existing installs.

composer outdated vendor/package
composer why-not vendor/package 2.12.0   # surfaces the blocker before you commit
composer update vendor/package --with-all-dependencies
php artisan config:clear && php artisan cache:clear

Run this on a branch. If why-not reports a laravel/framework constraint, that's the signal to schedule the Laravel 11 upgrade rather than force the package.

CI matrix. Since upstream now tests against three Laravel majors, mirror that in your own pipeline if the package is load-bearing — a matrix of Laravel 11/12/13 on your lowest supported PHP catches the resolver and deprecation issues before they reach production. Reserve a single "latest" job for Laravel 13.

Container/DI usage. Prefer constructor injection of the package's contracts over the facade in application services — it keeps your tests swappable and makes the binding visible during code review. Where the package exposes a facade, restrict it to controllers and artisan commands.

Testing. If the package touches the database, wrap feature tests in RefreshDatabase and seed through the package's own factories rather than hand-rolled fixtures. For anything that hits a third-party API, register the package's fake/stub in setUp() so the suite stays hermetic.

Dev container parity. The Docker image is the package's own development environment. If you're contributing upstream, use it as-is; if you're only consuming the package, your application's runtime PHP version is what matters and the container bump is irrelevant to you.

Gotchas and Tips

• The minimum-Laravel bump is the only breaking change here. Dropping Laravel 10 support will fail your composer require with an unhelpful-looking constraint error. Do not work around it with --ignore-platform-reqs or by editing composer.lock — the package genuinely no longer supports L10, and you'll get runtime failures that are much harder to trace.
• Laravel 13 support ≠ Laravel 13 stability. Verify the constraint the package declares (e.g. ^13.0 vs 13.x-dev) before adopting it in production; if it's a dev constraint you'll need "minimum-stability": "dev" and a prefer-stable entry, which affects your whole dependency graph.
• PHP 8.5 in the Docker image is a test-matrix change, not a requirement. The package's composer.json require.php constraint is the authoritative floor. Don't bump your app's PHP because the container did.
• Composer 2.10.0 in the container can rewrite plugin-api-version in a committed lock file. If your CI runs an older Composer, you'll see spurious lock-file diffs. Align the CI Composer version with the container's before merging contributor PRs.
• Dev-dependency updates are noise for consumers. They don't ship in the distributed package — skip them when writing your changelog entry, but do re-run your own test suite after the bump in case a transitive dev tool masked an issue.
• Config caching bites after upgrades. A stale cached config from a previous package version will keep old option keys alive and silently ignore new ones. Always php artisan config:clear post-upgrade on environments that cache.
• Extension points to check before forking. Published config, container bindings, and any documented macros/events are the intended customization surface. If you find yourself extending a concrete class, re-read the provider's register() first — there's usually a binding you can override instead.
• Debugging a silent no-op. If the package appears installed but does nothing, check in this order: composer show vendor/package (right version?), php artisan about (provider booted?), published config present?, then the package's log channel for swallowed exceptions.