Rabbitmq Bundle Laravel Package

Product Decisions This Supports

This is not a Laravel package. Despite the framing, wanupsml/rabbitmq-bundle is a Symfony2 bundle — a DI-container integration that wires php-amqplib producers and consumers into Symfony 2.x's service configuration. For a Laravel-based product it answers none of your questions directly; for a Symfony shop it answers questions about a framework generation that reached end-of-life in November 2018.

What it can inform, as a data point rather than a dependency:

• Build vs. buy for messaging infrastructure. The bundle's entire value proposition is "don't hand-roll AMQP connection management, exchange/queue declaration, and consumer wiring." That is a ~2–5 engineering-day problem in any modern framework. This package is evidence that the problem is small enough to be solved cheaply, and small enough that dozens of near-identical community solutions exist — which argues against paying for a commercial message-broker abstraction layer.
• Async vs. sync roadmap sequencing. Introducing AMQP is a genuine architectural commitment (broker operations, DLQs, idempotency, consumer deployment topology, on-call). If the roadmap item is "order confirmations shouldn't block checkout," a managed queue (SQS, Cloud Tasks, Redis-backed Laravel queues) delivers the user-visible outcome with a fraction of the operational surface. Reserve AMQP for routing-topology requirements — fan-out, topic exchanges, multi-tenant routing keys — that simpler queues genuinely cannot express.
• Framework-native vs. third-party abstraction. Modern equivalents already exist and are maintained: Symfony Messenger (first-party, Symfony 5.4+/6+/7) and vladimir-yuldashev/laravel-queue-rabbitmq (the de facto Laravel RabbitMQ driver). Choosing either means the abstraction is a supported, documented seam rather than a frozen snapshot of someone's 2015 config.
• Legacy modernization scoping. If a codebase still contains this bundle, treat it as a migration trigger, not a component to evaluate. Its presence dates the application to Symfony 2.x and, transitively, to unsupported PHP. That is a roadmap line item — "platform upgrade off EOL Symfony" — with a budget and an owner, not a package-selection decision.
• Vendor-risk policy calibration. Zero stars, zero dependents, zero score, no release cadence. This is a textbook example for defining the minimum adoption bar your team applies to any third-party dependency: maintained releases, a security-response path, a named maintainer, and at least one external production user you can point to.

Decision this assessment supports: do not adopt. The signal is not "low quality" — it is "no signal at all," and absence of evidence is disqualifying for anything touching production message flow.

When to Consider This Package

Adoption criteria — all of these must hold simultaneously:

• You maintain a live Symfony 2.x application that already depends on this bundle, and the immediate task is a patch, not a migration.
• The change is time-boxed and internal-facing, with a documented plan to exit the bundle within a defined window.
• You are vendoring or forking the code into your own repository so that upstream abandonment cannot break your build.
• Your team has already accepted Symfony 2.x and PHP 5.x as unsupported dependencies, so this adds no new class of risk.

You may also consult it — read, not install — as a reference implementation for how to structure producer/consumer configuration and connection lifecycle in an AMQP integration. Treat it as documentation, not as a dependency.

Look elsewhere when any of the following is true (in practice, nearly always):

• You are on Laravel. This bundle will not install, will not autoload usefully, and its service-container idioms do not map onto Laravel's. Use the Laravel queue system with the RabbitMQ driver, or php-amqplib directly behind a thin service class.
• You are on Symfony 4+. Use Symfony Messenger with the AMQP transport. It is first-party, actively maintained, and ships retry, failure-transport (DLQ), and middleware semantics the bundle predates.
• You need security patching. There is no maintainer, no advisory channel, and no release history to patch from. Any CVE in the underlying php-amqplib or AMQP protocol handling becomes your team's incident, unprompted.
• You need observability. No tracing hooks, no metrics, no structured consumer logging. Message-queue debugging without instrumentation is the single most expensive operational burden you can accept, and it is not something a 0-star bundle will solve for you.
• You need production-grade delivery semantics. Retry/backoff policies, dead-letter routing, poison-message quarantine, graceful consumer shutdown, and prefetch tuning are all things you will write yourself regardless. At that point the bundle contributes configuration sugar and little else.
• Your dependency policy has any floor at all. Zero dependents means zero external production validation. You would be the first adopter of an unmaintained package — an unbounded, uninsured risk for a component that sits directly on your revenue path.

Note on lineage: the naming and structure strongly resemble the long-standing oldsound RabbitMQBundle lineage (a widely used, well-starred Symfony integration that later moved under the php-amqp organization). If that is the case, this repository is a re-publish or fork with the community stripped away — the original may still be maintained, and the correct action is to use the upstream project, not this copy. Verify provenance before evaluating the ideas; there is no reason to inherit the artifact.

How to Pitch It (Stakeholders)

To executives — one paragraph: This package is not viable as a dependency and I do not recommend adoption. It is a Symfony 2 integration for RabbitMQ with zero stars, zero downstream users, and no maintainer presence — and Symfony 2 itself has been unsupported since 2018. Adopting it would place a critical, revenue-path component (message delivery) on code no one is obligated to fix, patch, or even notice breaking. The underlying capability we actually want — asynchronous processing so slow work doesn't block the customer — is available from our framework directly, at negligible cost. I'd frame this as a closed question rather than an open evaluation; the useful output is the adoption policy it lets us write.

To engineering — the substance: Don't take the dependency. Nothing here is technically novel or hard: connection management, exchange/queue declaration, and consumer wiring around php-amqplib is a few days of work, and the "modern" alternatives are not alternatives at all but the supported path — Symfony Messenger if we're on Symfony, the RabbitMQ queue driver if we're on Laravel. Either gives us retry and dead-letter semantics out of the box, plus a maintainer who answers security reports. Read this repo if you want a worked example of the config shape; do not put it in composer.json. If it appears anywhere in our tree today, that file is a signal we're running an EOL Symfony generation, and I want that surfaced as a migration ticket with a scope and an owner — not quietly patched around.

The risk we're actually avoiding: not "this code is bad," but "no one is accountable for this code." A message broker sits under checkout, notifications, and fulfillment. When it fails at 2 a.m., the resolution path must not terminate at a repository with zero watchers. That's the argument that lands, and it's the argument that should become a written minimum bar for every third-party dependency the team proposes.