Rabbitmq Bundle Laravel Package

Technical Evaluation

Architecture fit — the premise is wrong before the code is read. This is a Symfony bundle, not a Laravel package. It ships a Bundle subclass, a DependencyInjection\Extension that builds a configuration tree, and compiler passes that wire tagged producer/consumer services into the container. Laravel has no bundle/extension concept, so the package cannot be composer required into a Laravel app and "just work" — there is no service provider, no facade, no config publish tag, and no queue driver. Any Laravel integration would mean writing a bespoke bridge that reimplements the bundle's container wiring inside a ServiceProvider, at which point the bundle is contributing nothing but an abandoned config schema. Even in a Symfony app the fit is dated: the bundle targets Symfony 3.x/4.x-era conventions (XML/YAML service definitions, annotation-driven @RabbitMqConsumer, PHP 7.1–7.2), not attributes, autoconfiguration, or the modern AbstractBundle pattern.

Integration feasibility — effectively zero as distributed. Composer constraints will collide with any current project: the 2018 release line pins php-amqplib 2.x and Symfony 3/4 components. On PHP 8.2+ and Symfony 6/7 the transitive constraints fail resolution, and even with --ignore-platform-reqs you inherit PHP 7 fatal signatures (Serializable, dynamic properties, each()-era helpers). There is no lockfile-compatible path without forking the fork. The underlying transport (php-amqplib) is fine and maintained — but you do not need this package to use it.

Technical risk — high, and concentrated in the wrong places.

The score of 0.005 is not noise — it is the correct signal. A single-maintainer, unmaintained fork with zero downstream consumers means no one else is exercising these code paths in production, so you become the de facto maintainer on day one.

Key questions for the requestor.

1. Is the target application Laravel or Symfony? If Laravel, this package is disqualified on architecture alone — clarify what problem it was believed to solve.
2. What is the actual messaging requirement: fire-and-forget publish, competing consumers, RPC/reply_to, delayed messages, or dead-letter routing? Each maps to a different (maintained) package.
3. Is AMQP mandated by an existing broker/platform team, or is RabbitMQ a default that Redis/SQS could displace? Replacing the transport is cheaper than adopting a dead fork.
4. Who owns RabbitMQ operations (vhosts, policies, HA queues) and are they already a dependency?
5. Are we already pinned below PHP 8.1? If not, this is a non-starter regardless of anything else.

Recommendation: reject for adoption. Do not spend discovery time on a proof of concept; the compatibility ceiling is decisive and the maintenance posture is unrecoverable.

Integration Approach

Stack fit. Assume the requestor means Laravel (per the brief) — the correct answer is to drop this package and use vladimir-yuldashev/laravel-queue-rabbitmq, which is a first-class Laravel queue driver with a service provider, config publishing, Horizon-adjacent semantics, and active maintenance on current PHP/Laravel versions. If the stack is genuinely Symfony, use php-amqplib/rabbitmq-bundle — the maintained successor to the same codebase lineage, with attribute-based consumers and Symfony 6/7 support. In neither case does kch/rabbitmq-bundle belong in the dependency graph.

Migration path (from this package, if already present). Treat it as a rename-and-rewire, not a lift-and-shift:

• Swap the Composer requirement and vendor namespace; bundle class and extension alias change (old_sound_rabbit_mq → rabbitmq).
• Translate the configuration tree key-by-key — connection, producer, consumer, and multiple/qos blocks are broadly analogous but option names drift.
• Convert @RabbitMqConsumer/@RabbitMqProducer annotations to attributes (Symfony) or to Job/Queueable classes (Laravel).
• Re-validate exchange/queue/binding declarations against live broker state before cutover — declaration mismatches fail at runtime, not at boot.

Compatibility. Pin the replacement against your PHP and framework matrix explicitly and add a CI job that runs Composer resolution on the minimum and maximum supported versions. Add a composer audit gate plus Dependabot/Renovate — the failure mode you are avoiding is discovering a dead dependency two years later during an unrelated PHP upgrade.

Sequencing. (1) Confirm stack and messaging requirements. (2) Spike the replacement package against a disposable vhost with a real publish/consume round trip, including a poison message and a dead-letter route. (3) Land the driver swap behind a feature flag with dual-publish if message loss is unacceptable. (4) Cut consumers over per-queue, oldest-risk-last, with a soak window. (5) Remove the old dependency and its config in a separate, revertable PR. Budget roughly 1–2 weeks for a small team; the broker-side work, not the code, is the long pole.

Operational Impact

Maintenance. Adopting this package transfers upstream maintenance onto your team permanently: PHP 8 compatibility patches, php-amqplib major-version bumps, Symfony/Laravel deprecation cleanup, and any CVE in the AMQP client or its transitive tree. There is no release cadence to ride and no issue tracker where your bug reports will be triaged. This is the single largest hidden cost and it does not appear in any estimate that only counts integration hours.

Support. No vendor, no SLA, no security advisory channel, no community of practice — one star and zero dependents means no Stack Overflow corpus and no blog posts for the failure modes you will hit. Internal escalation becomes "read the fork's source and diff it against upstream." On-call engineers will be debugging code no living maintainer has touched since 2018.

Scaling. The transport itself scales fine — RabbitMQ is not the constraint. The constraints are in the bundle's ergonomics: connection setup and heartbeat tuning are manual and undocumented here, prefetch/QoS defaults are opinionated and easy to get wrong under load, and there is no built-in consumer supervision. You will need process managers (Supervisor/systemd), explicit pcntl-safe memory budgets for long-running consumers, and a plan for consumer crash-loops that do not poison the queue.

Failure modes to plan for explicitly.

• Silent consumer death — no health endpoint or heartbeat surfaced; without external supervision, queues grow until the broker hits watermarks and blocks publishers.
• Unbounded redelivery — misconfigured requeue on a poison message creates an infinite hot loop; requires DLX policies defined at the broker, not the bundle.
• Connection churn — 2018-era reconnect logic predates modern php-amqplib heartbeat handling; expect stale-channel errors after broker failover or idle timeouts.
• Declaration drift — exchange/queue mismatches between the bundle's config and the live broker fail late, at publish/consume time, often only under specific routing keys.
• PHP upgrade wall — the platform upgrade that eventually forces migration will arrive without warning and will block the whole application, not just messaging.

Ramp-up. Near-zero for the bundle's happy path (it is a thin wrapper), but the real learning curve is RabbitMQ operations — exchanges, bindings, DLX, QoS, and HA policies — which the package does not teach and the documentation does not cover. Assume 2–3 weeks before an engineer is independently safe in production, and pair that with broker-side runbooks (queue depth alerts, DLX drain procedure, replay tooling) that no package will give you.