Rabbitmq Bundle Laravel Package

Technical Evaluation

Architecture fit. wlogic/rabbitmq-bundle is a Symfony2 bundle, not a Laravel package. It is a thin configuration/integration layer over php-amqplib (and the older oldsound/rabbitmq-bundle lineage), providing producer/consumer abstractions, service-container wiring, and console commands for consuming queues. For a Laravel codebase there is no first-class fit: no service provider, no config publishing, no queue-driver contract implementation, no Artisan integration. Any Laravel use requires bypassing the bundle entirely and calling php-amqplib directly, or bridging the bundle's internals into a Laravel service container — which negates the value of adopting the bundle in the first place.

Integration feasibility. Low for a Laravel target, but non-trivial even for a Symfony target. The bundle assumes Symfony2-era conventions (service definitions in XML/YAML, KernelAwareInterface, older DI compiler passes) that diverge from Symfony 4+/5+/6+ autowiring and the modern Messenger component. In a Laravel app, you would be adopting a dead framework's idioms to talk to RabbitMQ — a strictly worse trade than using vladimir-yuldashev/laravel-queue-rabbitmq, which implements Laravel's native Queue contract and integrates with Horizon-style workers, retries, and failed-job handling.

Technical risk. High, and concentrated in three areas:

1. Project-signal risk. Zero stars, zero dependents, and a maintainer namespace (wlogic) with no visible community footprint. This is effectively an unmaintained private fork published publicly. The "last release 2026-02-10" timestamp is suspicious for a Symfony2-EOL package and should be verified — it may be a metadata artifact or an automated tag with no substantive changes.
2. Framework-EOL risk. Symfony2 reached end-of-life in 2018. The bundle's transitive constraints (PHP 5.x/7.x-era symfony/*, oldsound/rabbitmq-bundle, php-amqplib versions) will conflict with any modern Laravel/Symfony dependency graph and are unlikely to resolve cleanly in a PHP 8.2+ project.
3. Security/supply-chain risk. An unmaintained package with an obscure maintainer and low download counts is a poor candidate for production message-broker plumbing, which sits on the critical path for order processing, notifications, and async jobs.

Key questions for the maintainer / due diligence.

• Is this a maintained fork? What was forked from, and what is the fork's purpose?
• What is the actual supported matrix of PHP, Symfony, and php-amqplib versions?
• Does the 2026 release contain code changes or only metadata?
• Is there a security-disclosure channel?
• If we need RabbitMQ semantics (quorum queues, publisher confirms, DLX, TTL), does this wrapper expose them, or will we drop to php-amqplib anyway?

TPM verdict. Do not adopt. The correct lever is not this package but the decision underneath it: how do we do RabbitMQ from a PHP/Laravel stack? The answer is vladimir-yuldashev/laravel-queue-rabbitmq (or php-amqplib directly if we need low-level control). This bundle answers a question we are not asking.

Integration Approach

Stack fit. None as-is. Recommended stack fit is:

• Laravel 10/11/12 + PHP 8.2+ → vladimir-yuldashev/laravel-queue-rabbitmq (implements Illuminate\Contracts\Queue\Queue, works with queue:work, retries, failed_jobs, and Horizon-adjacent tooling).
• Symfony 6/7 → symfony/messenger with the AMQP transport (symfony/amqp-messenger). This is the modern successor to this bundle's role.
• Raw control needed (publisher confirms, custom topology, manual ack/nack) → php-amqplib/php-amqplib directly.

Migration path. Treat wlogic/rabbitmq-bundle as a reference implementation, not a dependency. Practically:

1. Inventory what the bundle does for us today (or would do): producer interfaces, consumer loop, ack strategy, retry/requeue behavior, DLX wiring.
2. Reimplement those concerns against the modern driver. In Laravel this is ~1 service provider, ~1 config file, and a job base class — days, not weeks.
3. If we have any existing code depending on the bundle (unlikely given zero dependents), migrate by wrapping the consumer command in an Artisan command or replacing it with queue:work --connection=rabbitmq.

Compatibility. The hard blocker is the Composer graph. Symfony2-era constraints will collide with Laravel 10+ (illuminate/* ^10, symfony/console ^6), and php-amqplib versions from that era lack PHP 8.1+ compatibility fixes. Expect composer require to fail or to force a dependency downgrade cascade — the classic "one unmaintained transitive forces us to freeze the whole graph" failure.

Sequencing. If the organization still wants to evaluate:

1. Week 1: Spike — composer require wlogic/rabbitmq-bundle in a throwaway Laravel 11 skeleton. Document whether it resolves. (Expect: no.)
2. Week 1: Competitive scan — benchmark against vladimir-yuldashev/laravel-queue-rabbitmq and symfony/amqp-messenger on feature coverage (publisher confirms, quorum queues, DLX, retry).
3. Week 2: Decide. Almost certainly: reject the bundle, standardize on the modern driver, and document the rejection rationale so it is not re-litigated.
4. Week 3+: Build the thin adapter (config + job base class + topology-as-code), then wire into the first async workflow.

Operational Impact

Maintenance. Effectively zero upstream maintenance. A single-maintainer namespace with zero stars and zero dependents implies no triage capacity, no CI signal, and no incentive to respond to PHP/Symfony upgrades. Owning this means we own the code: security patches to php-amqplib, PHP version bumps, and framework compatibility are all our problem. Budget it as a vendored-and-owned component, not a dependency.

Support. No community forum, no documented support channel, no downstream users to learn from. Institutional knowledge will be a single engineer. That is a key-person risk on the message-broker critical path — the worst place to have one.

Scaling. The bundle's consumer model is the Symfony2-era rabbitmq:consumer long-running loop: one process, one channel, prefetch-tunable. That model can scale horizontally (N worker processes) but provides no built-in coordination with modern autoscaling, no per-queue worker pools, and no integration with Laravel's worker/pool/Horizon semantics. Throughput ceiling is php-amqplib-bound, which is fine — but every operational affordance (graceful shutdown, SIGTERM handling, --timeout, --memory, queue:restart-style recycling) must be hand-built. Modern drivers give these for free.

Failure modes. Concrete ones to plan for:

• Stale-consumer leaks — long-running PHP loops accumulating memory or DB connections without a recycle policy. Standard php-amqplib guidance is --max-messages; confirm it exists and is enforced.
• Ack/nack correctness — a wrapper that acks before job completion silently drops messages on worker crash. Must be audited, not assumed.
• Poison-message / no DLX — without a dead-letter topology, a failing job requeues forever and starves the queue.
• Dependency drift — the day php-amqplib patches a CVE, the bundle's pinned constraint may prevent upgrade; if it does, we are patching a fork under incident pressure.
• Composer resolution failure on PHP upgrade — a scheduled, low-drama version bump becomes a multi-day project.

Ramp-up. Counterintuitively higher than the modern alternatives, because engineers must learn a framework idiom (Symfony2 DI + bundle config) that has no transferability to the rest of the codebase, on top of AMQP semantics they need regardless. Expect 1–2 days for an engineer familiar with Symfony2, 3–5 days for a Laravel-native engineer with no Symfony2 exposure — and that knowledge is then stranded. By contrast, the Laravel-native driver is ~2 hours: it looks like every other Laravel queue connection.

Bottom line. Opportunity score of ~40 reflects the domain (RabbitMQ integration in PHP is real, valuable, and under-served in the Laravel ecosystem) but the artifact itself is a Symfony2-era fork with no community, no dependents, and no maintenance posture. The TPM recommendation is to capture the opportunity with the modern driver — vladimir-yuldashev/laravel-queue-rabbitmq for Laravel, symfony/amqp-messenger for Symfony — and formally reject this bundle with documented rationale.