- Can I install kch/rabbitmq-bundle in a Laravel application?
- No. The package is a Symfony bundle that ships a Bundle subclass, a DependencyInjection Extension, and compiler passes, none of which Laravel can load. Composer may fail outright on modern PHP because it pins php-amqplib 2.x and Symfony 3/4 components. Even with --ignore-platform-reqs there is no service provider, facade, config publish tag, or queue driver to register. It cannot be composer required into a Laravel app and just work.
- Does kch/rabbitmq-bundle support Laravel 10 or Laravel 11?
- No. There is no Laravel integration layer at all: no service provider, no facade, no config publishing, and no queue driver. Its Composer constraints target Symfony 3.x/4.x-era components and PHP 7.1–7.2, so dependency resolution fails on current Laravel stacks. The package cannot be installed as a Laravel dependency without forking and rewriting its container wiring.
- Why is kch/rabbitmq-bundle not a Laravel package?
- Its architecture is Symfony-specific: it relies on Bundle registration, an Extension configuration tree, and compiler passes that wire tagged producer and consumer services into the container. Laravel has no bundle or extension concept, so there is nothing for the framework to discover or boot. Any Laravel use would require a bespoke bridge that reimplements the bundle's container wiring inside a ServiceProvider, at which point the bundle contributes only an abandoned config schema.
- What Laravel package should I use instead of kch/rabbitmq-bundle for RabbitMQ?
- Use vladimir-yuldashev/laravel-queue-rabbitmq, which is a first-class Laravel queue driver with a service provider, config publishing, and active maintenance on current PHP and Laravel versions. If your stack is genuinely Symfony, use php-amqplib/rabbitmq-bundle, the maintained successor to the same codebase lineage. The underlying php-amqplib transport is fine and maintained, but you do not need this package to use it.
- Is kch/rabbitmq-bundle maintained or abandoned?
- It is effectively abandoned. The last release was 2018-06-15, leaving roughly seven years of upstream drift. It has one star and zero dependents, and the vendor namespace is an internal fork of a payday-loan company with no external review, security policy, or CVE feed. It is also a fork of oldsound/rabbitmq-bundle, itself superseded by php-amqplib/rabbitmq-bundle, so bug fixes land upstream and never here.
- Does kch/rabbitmq-bundle work with PHP 8.2 or PHP 8.3?
- No. The 2018 release line targets PHP 7.1–7.2 and you inherit PHP 7 fatal signatures such as Serializable and dynamic-property issues, plus each()-era helpers. On PHP 8.2+ and Symfony 6/7 the transitive constraints fail resolution outright. There is no lockfile-compatible path without forking the fork, and it blocks platform upgrades indefinitely.
- How do I configure producers and consumers in kch/rabbitmq-bundle?
- In a Symfony app the bundle exposes a configuration tree for connections, producers, and consumers, and wires tagged producer/consumer services plus annotation-driven @RabbitMqConsumer classes into the container. That is Symfony extension and compiler-pass behavior, not Laravel configuration. Laravel has no equivalent extension loading, so there is nothing to configure without writing a custom bridge from scratch.
- Can I use kch/rabbitmq-bundle with Symfony 6 or Symfony 7?
- No. The bundle follows Symfony 3.x/4.x-era conventions such as XML/YAML service definitions and annotation-driven consumers, not attributes, autoconfiguration, or the modern AbstractBundle pattern. Its Composer constraints and PHP 7-era code conflict with Symfony 6/7 and PHP 8.x. For current Symfony, use php-amqplib/rabbitmq-bundle, which supports Symfony 6/7 and attribute-based consumers.
- What are the risks of using kch/rabbitmq-bundle in production?
- The risks are high and concentrated: critical abandonment since 2018, critical runtime incompatibility with PHP 8.x, and high supply-chain uncertainty from a single-maintainer fork with one star and no downstream consumers. You also inherit medium behavioral debt such as legacy connection/reconnect semantics, no health checks, and no observability hooks. With no one else exercising these code paths in production, you become the de facto maintainer on day one. The recommendation is to reject it for adoption rather than spend discovery time on a proof of concept.
- How do I migrate from kch/rabbitmq-bundle to a maintained alternative?
- For Laravel, drop this package and install vladimir-yuldashev/laravel-queue-rabbitmq, configure a RabbitMQ queue connection, and replace dispatch calls with the standard Laravel queue API. For Symfony, move to php-amqplib/rabbitmq-bundle and convert consumers to attribute-based definitions. Do not build a bridge to keep the old bundle alive; the compatibility ceiling is decisive and the maintenance posture is unrecoverable.