- Does enqueue/messenger-adapter work with Laravel?
- Not natively. It is a transport shim between Symfony Messenger's TransportInterface and Enqueue brokers, while Laravel uses Illuminate\Contracts\Bus\Dispatcher and Illuminate\Queue drivers. It only makes architectural sense in Laravel if you deliberately adopt Symfony Messenger's bus and envelope model, usually to share message contracts with Symfony services or to reach a broker Symfony does not support natively. For a standard Laravel workload it adds a second messaging stack with separate workers, retries, and serialization.
- How do I install enqueue/messenger-adapter in a Laravel project?
- Installation is a single Composer line, but the README's install command references the legacy sroze/messenger-enqueue-transport name while the repository is enqueue/messenger-adapter. Resolve the canonical Packagist package and version before adding it to your lockfile. In Laravel you will also hand-write a service provider and configuration loader because the documented setup assumes Symfony Flex, enqueue/enqueue-bundle, and YAML under config/packages. There is no Laravel recipe for this package.
- Why would a Laravel team use Symfony Messenger instead of Laravel queues?
- The usual reason is shared message contracts and consumers with Symfony services elsewhere in the estate, where adopting Messenger's bus, middleware, and envelope model avoids duplicating contracts. The other reason is needing a broker Symfony does not support natively, such as Kafka, STOMP, or Gearman, while keeping Messenger semantics. If neither applies, Laravel's queue drivers or a direct Enqueue integration are simpler.
- Which message brokers can I use with this adapter?
- It supports any broker that Enqueue supports, including AMQP, Redis, Kafka, STOMP, and Gearman. You point Messenger at enqueue://default and configure the underlying Enqueue transport through its DSN. For common brokers like AMQP, Redis, and SQS, Laravel or Symfony native drivers may be a better fit.
- Can I use enqueue/messenger-adapter with Laravel Horizon or Laravel's queue workers?
- No. Horizon and Laravel queue workers are built around Illuminate\Queue jobs and drivers, not Symfony Messenger transports. This adapter requires Messenger's own consume command and worker runtime, so you would run two parallel worker systems. That means two retry models, two dead-letter approaches, and two observability setups.
- How do I configure queues, exchanges, delays, TTL, and priority?
- You set common options as query parameters on the transport DSN, such as queue[name], topic[name], deliveryDelay, timeToLive, receiveTimeout, and priority. Per-message overrides use the TransportConfiguration stamp, which exposes convenient methods like setDeliveryDelay and maps additional metadata to broker-specific setters. Because Laravel has no YAML config layer here, you will need to build these DSNs and stamp usage into your own service provider or message bus configuration.
- How do I consume messages in a Laravel application?
- The documented consumer is bin/console messenger:consume amqp, a Symfony Console command that expects a Messenger service locator, routable bus, and event dispatcher. Registering that with Artisan is real glue code, not configuration. You will need an Artisan command or wrapper that boots the Messenger consume loop and handles signals, health checks, and failure-transport replay.
- Is enqueue/messenger-adapter actively maintained and safe for production?
- Treat it as moderate-to-high maintenance risk. The project has roughly 201 stars, zero dependents, a composite score near 24/100, and no evidenced security policy, so there is little community buffer if it breaks. The code is a thin adapter, so a defect's blast radius is small, but upstream drift in Messenger's TransportInterface or Enqueue's transport API can break it. MIT licensing means fork-and-patch is a legitimate contingency.
- What Laravel and PHP versions does enqueue/messenger-adapter support?
- The package targets Symfony Messenger and Enqueue, so compatibility follows their Composer constraints rather than Laravel's release cycle. Check the Packagist metadata for the exact Symfony Messenger, Enqueue, and PHP versions allowed, and verify the canonical package name before installing. Do not assume Laravel version support is documented, because the README is written for Symfony applications.
- What alternatives should Laravel developers consider before using this adapter?
- For standard async jobs, use Laravel's queue drivers such as Redis, SQS, database, or a community AMQP driver. For Kafka or STOMP from Laravel, integrate Enqueue directly rather than routing through a Symfony Messenger adapter. Only choose enqueue/messenger-adapter when Messenger semantics or shared Symfony message contracts are a hard requirement.