- Is nti/rabbitmq-bundle compatible with Laravel?
- No. It is a Symfony bundle that ships a Bundle class, a DependencyInjection extension, and a config-tree-driven consumer and producer definition system, none of which Laravel can autoload or boot. Laravel has no equivalent bundle lifecycle hook, so the package's autoconfiguration is inert inside a Laravel app. Making it work means forking or manually wiring its connection factory, producers, and consumers through Laravel's container and rebuilding the config tree as config files.
- How do I install nti/rabbitmq-bundle?
- You install it with Composer, register the bundle in config/bundles.php, and define your exchanges, queues, producers, and consumers under the bundle's config root key. Consumers are then run through the bundle's console command, typically under supervisord. In Laravel there is no extra.laravel discovery entry, so a plain composer require does nothing on its own.
- Which PHP and Symfony versions does nti/rabbitmq-bundle support?
- The last release was published on 2021-06-08 and targets PHP 7.x and 8.0 with Symfony up to the 5.x line. Expect deprecation notices and possible runtime breakage on PHP 8.2 or 8.3 and on Symfony 6 or 7. Verify your exact runtime matrix before adding it to composer.json.
- Can I use nti/rabbitmq-bundle as a Laravel queue driver?
- No. It does not implement Laravel's queue contracts, so it cannot back the Queue facade, dispatch jobs, handle failed-job tables, or participate in Laravel's worker and retry semantics. It provides its own CLI consumer loop built on php-amqplib instead. For a real Laravel queue driver use a Laravel-native package such as vladimir-yuldashev/laravel-queue-rabbitmq.
- Is nti/rabbitmq-bundle still maintained?
- There is effectively no maintenance signal: zero stars, zero dependents, and a last release from June 2021. It is a single-maintainer rebrand of oldsound/rabbitmq-bundle, which was itself deprecated and superseded. No security advisories will be issued and no PHP 8.1+ deprecation fixes are expected, so you inherit the patching obligation yourself.
- What is the best Laravel alternative to nti/rabbitmq-bundle?
- For Laravel, use vladimir-yuldashev/laravel-queue-rabbitmq, which is a maintained queue driver that plugs into Laravel's native worker, retry, and failed-job handling. If you only need a raw AMQP connection rather than queue abstractions, depend on php-amqplib/php-amqplib directly and wrap it in a small service of your own. On the Symfony side, php-amqplib/rabbitmq-bundle is the maintained successor.
- How does nti/rabbitmq-bundle differ from oldsound/rabbitmq-bundle?
- Functionally it is a rebrand: the package name is a namespace swap and the API surface, including the consumer base class and config structure, is essentially unchanged. That makes it a drop-in for Symfony projects still on the old package name. However, the maintained upstream is php-amqplib/rabbitmq-bundle, so prefer that unless you have a specific reason to stay on this fork.
- Does nti/rabbitmq-bundle support async or high-throughput messaging?
- No. It is built on php-amqplib, which is synchronous and blocking, so there is no native async I/O. Consumers are long-lived forked CLI processes that you must supervise yourself with something like supervisord. That model is a poor fit for containerized or serverless deployments and caps throughput compared with async clients or a managed broker.
- What are the production risks of depending on nti/rabbitmq-bundle?
- The main risks are provenance and supply chain: a single-maintainer fork with no downstream users gives you almost no signal that issues will be caught or patched. It also lags on runtime currency and carries a synchronous process model that needs its own supervision story. Before adopting it, decide explicitly who owns patching php-amqplib and this bundle when a CVE lands in the dependency tree.
- How do I migrate from oldsound/rabbitmq-bundle or off nti/rabbitmq-bundle?
- In Symfony, swap the Composer requirement, update bundle registration in config/bundles.php, rename the config root key if it changed, and diff the consumer base class; the API has historically been stable. Moving toward the maintained php-amqplib/rabbitmq-bundle follows the same steps plus reconciling any fork-specific local patches in the git log. Do not attempt this migration in Laravel at all; replace the dependency with a Laravel-native queue driver instead.