Humus Amqp Bundle Laravel Package

Product Decisions This Supports

• Framework-mismatch check first. Despite the "Laravel/PHP package" framing, this is a Symfony bundle. It does not inform any Laravel roadmap decision directly; its only relevance to a Laravel-centric product is as a comparison point when evaluating AMQP integration options (Symfony Messenger's AMQP transport, vladimir-yuldashev/laravel-queue-rabbitmq, or Enqueue are the Laravel-native equivalents).
• Build-vs-buy on integration glue. The package's entire value is the Symfony wiring layer over HumusAmqp: DI service definitions for producers/consumers, configuration for exchanges/queues/bindings, and console commands for running consumers. That is a few days of work to build in-house. The decision hinges on whether the ~3 days saved outweighs adopting a dependency with 3 stars and 0 dependents.
• Delivery-semantics requirements. Useful when the product needs real AMQP 0-9-1 broker semantics — routing keys, exchanges, fan-out, prefetch/QoS, dead-lettering, delayed retries — rather than a simple job queue. This is the class of decision where the broker topology matters more than the library.
• Use cases it enables: async event fan-out between internal Symfony services, decoupling slow side effects (email, webhooks, PDF generation, third-party sync) from the request path, retry/DLQ pipelines, and RPC-style request/reply between services.
• What it explicitly does not support: any decision to standardize on a messaging abstraction. It is bound to HumusAmqp; it is not a portable transport layer. Choosing it narrows future options.
• Symfony 7 is now a confirmed target, not an assumption. v2.3.0 adds Symfony 7 component support, which removes the "will this even install on our current LTS?" unknown from the evaluation. It does not change the strategic picture: the release is a compatibility bump, not a maintenance-commitment signal.
• Health-score signal. Still 0 dependents with a thin star count — a governance input, not just a quality input. It tells you no other team has stress-tested this in production and there is no de facto support community to escalate to. One release after a long quiet period softens the "abandoned" read slightly; it does not create a support community.

When to Consider This Package

Consider it when:

• You are already on Symfony (6/7 confirmed via v2.3.0; 4/5 per the package's own constraint range) and have already committed to HumusAmqp as your AMQP client — in which case this is the shortest path from "library installed" to "consumer running under bin/console."
• You need RabbitMQ/AMQP 0-9-1 topology (exchanges, bindings, routing keys, DLX) and want it expressed as Symfony config rather than hand-wired PHP.
• You can run the ext-amqp C extension in your runtime (this is a hard prerequisite, and it rules out many serverless/managed-runtime environments).
• Your team is capable of reading the bundle's source, pinning a version, and forking it into an internal namespace if the upstream goes quiet again.

Look elsewhere when:

• You are on Laravel. Use Symfony Messenger's AMQP transport as a standalone component, or a Laravel queue driver. The bundle's Symfony kernel coupling makes it a poor fit.
• You have not yet chosen an AMQP client. The client choice (HumusAmqp vs. Enqueue vs. php-amqp directly) is the strategic decision, and this package is downstream of it. Enqueue and Symfony Messenger have materially more adoption and first-party maintenance than HumusAmqp.
• You need a supported dependency. 3 stars, 0 dependents, no evidence of a security-response process, and a single compatibility release — v2.3.0 — following a roughly two-year gap. If procurement or security review requires an active maintainer cadence or a CVE SLA, this still fails; a Symfony 7 bump is table stakes, not a roadmap.
• Your queues are managed cloud services (SQS, Pub/Sub, Azure Service Bus) rather than a broker you operate.
• You need a spike-level answer fast. For a two-week proof of concept, a direct php-amqp consumer is fewer moving parts than adopting two dependencies (HumusAmqp + this bundle).

How to Pitch It (Stakeholders)

To executives: This is glue, not a platform. It saves a handful of engineering days on a Symfony service that has already chosen the HumusAmqp client, by making broker topology configuration-driven and consumers runnable from the console. That is its entire scope. The latest release (v2.3.0) adds Symfony 7 support, which is genuinely useful — it means the bundle keeps working as we move onto a current Symfony LTS — but it is a maintenance bump, not a sign of investment: MIT-licensed, three GitHub stars, zero dependent projects, and one release after a long quiet period. Recommendation: do not make it a strategic or long-lived dependency. If we use it, we scope it to one internal service, pin the version, and budget a day to fork it internally if upstream stalls again.

To engineering: It is a thin Symfony DI/config/console layer over HumusAmqp; the real logic lives upstream. Requires ext-amqp. v2.3.0 lifts the Symfony constraint to include Symfony 7 — verify our pinned Symfony minor is inside the new constraint, re-check the Composer resolution against our HumusAmqp version, and confirm the config schema still covers our exchange/queue/DLX topology. Then write an integration test against a real broker; unit coverage in a bundle like this is typically shallow, and a compatibility-only release is exactly the kind of change that ships without behavioural tests. Treat it as vendored code: readable, patchable, and expected to be maintained by us, not by the author.

Framing the recommendation: the honest one-liner is "this is a convenience wrapper for a narrow stack combination; it is not a reason to choose that stack — and v2.3.0 makes it installable, not strategic." Approve it only as a rider on an existing HumusAmqp decision, never as the thing that drives one.