Rabbitmq Bundle Laravel Package

Getting Started

Before installing anything, understand what you are looking at: gepur-it/rabbitmq-bundle is a Symfony bundle, not a Laravel package. It registers itself via the Symfony bundle/kernel mechanism (Bundle class, DependencyInjection extension, likely a services.yaml), and it has no ServiceProvider, no Facade, and no Laravel config integration. So "installing it in Laravel" is not a supported path. You can still consume its underlying connection-building code, but you will be wiring it yourself.

The package is still alive in a maintenance-only sense: v5.3.0 shipped with a single line of release notes — "allow php 7.4". That is a composer.json constraint widening, nothing more. Read it precisely: it lowers the PHP floor to 7.4, it does not announce PHP 8.x validation, Symfony 6/7 support, or a php-amqplib major-version bump. Treat every other assumption from the previous release as unchanged.

With that caveat, the minimal path if you are working in a Symfony app (or a Symfony service that lives alongside a Laravel app):

1. composer require gepur-it/rabbitmq-bundle — pin the version explicitly (^5.3). The project has a history of long silences between releases, so an unpinned constraint is a liability, not a convenience.
2. Register the bundle in config/bundles.php (GepurIt\RabbitMqBundle\RabbitMqBundle::class => ['all' => true] — verify the exact FQCN from the source tree before trusting this).
3. Look first at src/DependencyInjection/ (the Configuration class and the *Extension class). That is the authoritative list of config keys, service IDs, and aliases. Do not trust README snippets over the actual Configuration::getConfigTreeBuilder().
4. Run bin/console config:dump-reference <alias> to print the live config tree. This is the fastest way to see what the bundle actually accepts.
5. Create config/packages/<alias>.yaml (likely rabbitmq.yaml or gepur_rabbitmq.yaml) with host/port/user/password/vhost, and then inject the connection service wherever you publish or consume.

First real use case: a single producer. Get a message onto a queue via whatever service the bundle exposes (probably a connection or channel factory wrapping PhpAmqpLib\Connection\AMQPStreamConnection), confirm the exchange/queue binding, and only then tackle a consumer. Producers are where a thin connection wrapper earns its keep; consumers are where you need reconnect and ack semantics that this bundle may not give you.

Implementation Patterns

Reality check first. Low stars, effectively no dependents, and a release cadence measured in years. The v5.3.0 notes being one line about PHP 7.4 tells you the maintenance mode: constraint hygiene, not feature work. Treat it as a code sample you vendor, not a dependency you trust for anything beyond opening a connection. In almost every Laravel codebase the correct pattern is:

• Use vladimir-yuldashev/laravel-queue-rabbitmq if you want RabbitMQ as a Laravel queue driver (jobs, workers, retries, queue:work).
• Use php-amqplib/php-amqplib directly if you need raw AMQP semantics (manual ack, prefetch/QoS, custom exchanges).
• Only reach for this bundle if you are literally in a Symfony app that already uses it, or you are copying its connection-factory pattern into a Laravel service provider.

Producer pattern (if you are adapting the bundle). The bundle's real value is encapsulating connection config into one place. Replicate that: bind a singleton connection in a Laravel service provider, and inject it into publisher classes. Keep exchange name and routing key out of the connection service — pass them per-publish.

Symfony-side pattern (the supported path). Register the bundle, configure credentials in the bundle's YAML block, and inject its connection/channel service into your own services via autowiring or an explicit arguments: entry. If the bundle exposes a factory with named services per connection, prefer one connection per business domain rather than one global connection — it keeps channel-level failures isolated.

Bridge into Laravel if you must. A pragmatic integration:

1. Add the bundle as a plain library (composer require gepur-it/rabbitmq-bundle), and accept that the Symfony Bundle class is inert under Laravel.
2. In App\Providers\RabbitMqServiceProvider, read config('rabbitmq.*') and construct the underlying AMQPStreamConnection yourself — either by reusing the bundle's connection class or by writing ~15 lines against php-amqplib.
3. $this->app->singleton(Connection::class, ...) and inject into publishers.
4. Do not try to make it a queue driver. Laravel's queue contract (push, pop, later, ack, release) has retry/visibility semantics the bundle does not implement. You will fight it.

Consumer pattern. If you write your own worker (Laravel queue:work won't apply), run it as a supervised long-lived process (Supervisor), set basic_qos prefetch explicitly, and handle ack/nack yourself. Never run an AMQP consumer inside an HTTP request.

Gotchas and Tips

• It is not a Laravel package. No ServiceProvider, no Facade, no config/rabbitmq.php auto-publish, no Illuminate\Queue integration. Any guide implying otherwise is wrong.
• v5.3.0 is a constraint change, not a compatibility statement. "Allow php 7.4" means the composer.json php requirement was widened downward. It does not mean the maintainer ran the suite against PHP 8.2/8.3/8.4, validated Symfony 6/7, or bumped php-amqplib. Diff composer.json between your pinned version and 5.3.0 before upgrading; a one-line release note often hides nothing else, but verify rather than assume.
• Semver reading. v5.3.0 is a minor bump, so no breaking API change is promised — but for a package this thinly maintained, treat the changelog as marketing and the composer.json diff as truth.
• Abandoned-adjacent status. Long gaps between releases, minimal release notes, and no advisory coverage. Do not expect fixes for PHP 8.x deprecations, Symfony 6/7 incompatibility, or php-amqplib major-version breaks. Expect to fork or vendor. The 5.3.0 release is a reason to check whether the package is still resolvable against your stack — not a reason to trust it more.
• Transitive AMQP version pinning. Bundles like this typically constrain php-amqplib tightly. If another dependency needs a newer php-amqplib, you get a composer conflict you cannot resolve without a fork. Decide early.
• Config quirk: config vs. env. Symfony bundles of this vintage often expect literal YAML values and do not auto-read %env()% — verify how the extension resolves %env(RABBITMQ_HOST)% and whether defaults are baked in. A null DSN that silently falls back to localhost:5672/guest is the classic 45-minute debug session.
• No reconnect logic. Short-lived HTTP producers are usually fine; long-lived consumers will die on broker restart or network blip and stay dead. Add your own reconnect loop with backoff, or use a library that has one.
• Channel reuse and thread safety. PhpAmqpLib connections are not safe to share across processes; channels are cheap, connections are not. Keep one connection per process and do not fork after connecting (relevant under Octane/queue workers).
• Debugging checklist: confirm credentials with rabbitmqctl list_connections, check the management UI for the actual exchange/queue names, and enable php-amqplib's protocol logging if the bundle swallows exceptions. A silent publish almost always means the exchange name is wrong or not declared — set passive: false and declare idempotently.
• Extension points are limited. Because it is a thin wrapper, the only real hook is decorating the connection service. If you need publisher confirms, mandatory flags, or per-message TTL, plan to bypass the bundle wrapper and call php-amqplib directly.
• Recommendation: if this is a greenfield Laravel project, do not adopt it. If it is an existing Symfony service you must interface with, keep it as the connection factory and treat everything above AMQP primitives as your own code. The 5.3.0 release slightly improves your odds of a clean composer require on a mixed-PHP fleet — it does not change the maintenance story.