Rabbitmq Bundle Laravel Package

Product Decisions This Supports

• Framework-fit decision (the big one). Despite arriving in a "Laravel/PHP package" evaluation, this is a Symfony2 bundle, not a Laravel package — no service provider, no publishable config, no facade, no queue-driver integration. Its only real product value in a Laravel context is as a reference implementation of AMQP producer/consumer wiring, not as a dependency. Decision it informs: do not add to a Laravel service; route to vladimir-yuldashev/laravel-queue-rabbitmq or php-amqplib directly.
• Build vs. buy for async messaging. The bundle buys you DI-configured producers/consumers on top of php-amqplib. It buys you nothing for the expensive parts — topology design, dead-letter queues, retry/backoff policy, idempotency, poison-message handling, observability. Budget those as engineering work regardless of package choice; don't let "we picked a bundle" read as "messaging is solved."
• Legacy estate signal. Any team asking for this is implicitly telling you they still run Symfony 2.x (EOL since 2019). That's a modernization roadmap input, not a procurement request. Treat the ticket as a migration flag.
• Vendor-risk posture. 0 stars, 0 dependents, single-maintainer fork lineage. Decision it supports: no new strategic dependency on unmaintained framework branches; if adopted at all, isolate behind an internal MessageBus/Publisher interface so it's swappable in one PR.
• Roadmap prioritization. Async job processing and event fanout are legitimate roadmap items; this package should not appear on the roadmap as an enabler. The enabler is "pick a maintained transport + own the topology."
• Due diligence trigger. Before any approval, confirm this is a maintained fork of php-amqplib/RabbitMqBundle, verify release cadence, CI status, and open security advisories. A 2026-02-10 release tag with zero stars warrants a provenance check, not a celebration.

When to Consider This Package

Consider only if all of these hold:

• The service is Symfony 2.8/3.x, still in production, and being kept alive short-term.
• You're already on, or committed to, php-amqplib and want YAML/XML-configured producers and consumers with minimal glue code.
• The team accepts pinning to an EOL Symfony branch and owning the bundle's code if it breaks.
• Scope is narrow: publish/consume wiring only. No schema registry, no advanced routing, no SLA.

Look elsewhere if any of these hold:

• Any Laravel codebase — wrong framework entirely. Use laravel-queue-rabbitmq for queue-driver parity with Laravel's queue API, or php-amqplib for direct control.
• Symfony 5/6/7 — use Symfony Messenger with the AMQP transport. First-party, maintained, covered by Symfony's BC and security policy. This is the default recommendation for greenfield Symfony work.
• You need managed-broker ergonomics (CloudAMQP, Amazon MQ, SQS), schema governance, or out-of-the-box retry/DLQ semantics — none of which this bundle provides.
• You need vendor support, an SLA, or a security-response commitment. Zero stars and zero dependents means bus factor ≈ 1 and no community backstop.
• Your architecture is framework-agnostic microservices — a framework bundle is the wrong abstraction layer; depend on php-amqplib or an AMQP-neutral client.

How to Pitch It (Stakeholders)

Executive summary. wlogic/rabbitmq-bundle is a thin Symfony2 integration layer over the standard PHP AMQP client. It is not a Laravel package and is not a fit for our Laravel services. Adoption carries no licence cost but meaningful ownership cost: effectively no community, no dependents, and a single-maintainer fork lineage behind it.

Recommendation: do not adopt for new work. For Laravel, standardize on laravel-queue-rabbitmq (queue-driver parity, maintained) or php-amqplib (full control). For Symfony, standardize on Symfony Messenger's AMQP transport, which is first-party and covered by Symfony's release and security policy.

If a team escalates a genuine Symfony 2 blocker: approve a timeboxed spike — one engineer, one to two days, proving publish/consume against a non-production broker — and require the bundle be wrapped behind an internal publisher interface so removal is a single change. Cap the commitment; do not let it become an architectural dependency.

For engineering. The bundle solves wiring, not messaging. You still own topology, DLQ/retry policy, idempotency, and observability. The 2026-02-10 release date should be verified against actual tags, CI status, and any security advisories before code lands — treat that verification as a merge gate.

Trade-off in one line: near-zero acquisition cost, non-zero and unbounded ownership cost; the maintained alternatives cost the same to acquire and materially reduce bus-factor and upgrade risk.