Messenger Enqueue Transport Laravel Package

Product Decisions This Supports

• Build vs. buy for async messaging plumbing. This package is a thin adapter that lets an application keep Symfony Messenger's programming model (handlers, middleware, retries, failure transport, routing) while delegating the wire protocol to an Enqueue-backed broker (AMQP, Redis, Kafka, SQS, STOMP, Google PubSub, etc.). That is a "buy/reuse" decision that removes the need to hand-roll broker-specific producers and consumers.
• Deferred broker commitment. Useful when the broker choice is not final — per-environment transports (Redis in dev, AMQP in production, cloud queue in one region) can be swapped behind a stable application-level abstraction. This is a strategic option value, not just a technical convenience.
• Roadmap: standardizing on Messenger as the internal message/event abstraction. The 0.8.0 → 1.0.0 jump is the most decision-relevant fact in this release. A 1.0.0 tag is a stability and API-commitment signal, which is what makes it defensible in an architecture decision record; a 0.x dependency usually is not.
• Migration paths in both directions. Legacy Enqueue-based services moving onto Messenger, or Messenger-based services that need broker coverage the core transports don't offer. This package is the bridge in either direction.
• Laravel scope check (important). This is a Symfony Messenger transport, not a Laravel queue driver. In a Laravel codebase it is only relevant if you have deliberately adopted Symfony Messenger alongside or instead of Laravel's native queue system. It does not replace QUEUE_CONNECTION, Horizon, or illuminate/queue. Treat "Laravel/PHP package" here as "PHP package that a Laravel team could use," not "drop-in Laravel feature."
• Upgrade-cost forecasting. Dropping EOL Symfony versions is a forced-upgrade decision for anyone pinned to older Symfony branches; 1.0.0 turns that into a scheduling item for the platform roadmap.

When to Consider This Package

Adopt when:

• You already use (or are committing to) Symfony Messenger and need broker coverage beyond the built-in AMQP/Redis/Doctrine/Beanstalkd transports.
• You want one transport layer across multiple brokers or protocols, or need a broker the core transports don't support (STOMP, SQS, Kafka, Google PubSub via Enqueue).
• You are on a maintained PHP and Symfony line. The release notes say "Add Symfony 8; drop EOL versions," so the floor has moved. Verify the exact PHP and Symfony constraints in composer.json before planning the bump — the notes do not state the new minimums, and this is the single highest-risk unknown in the release.
• You are comfortable owning an extra dependency chain (this package plus the underlying enqueue/* transport libraries) and tracking its compatibility with each Symfony major.

Look elsewhere when:

• The app is a straightforward Laravel product. Use Laravel's native queues and Horizon. Adding Messenger plus Enqueue to a Laravel app is a large architectural bet for a package that is not built for that ecosystem.
• You only ever need one broker that core Messenger already supports. The built-in transport is simpler, better documented, and has more users.
• You need a vendor SLA, commercial support, or guaranteed security-response timelines. This is a single-maintainer OSS adapter; budget for the possibility of forking or replacing it.
• You cannot absorb a major-version bump this cycle. Going 0.8.0 → 1.0.0 is the moment to pin, test, and stage the upgrade rather than float the constraint.
• Your Symfony version is still in the dropped-EOL set. You would be upgrading Symfony to adopt this, which inverts the cost/benefit.

On this specific release: there are no new features. It is a compatibility and maintenance release — Symfony 8 support, EOL Symfony branches removed, and a PHP 8.4 nullable-configuration fix in php-cs-fixer. Note that the php-cs-fixer change is a dev-tooling/CI detail with no runtime effect; do not let it appear in a risk assessment as a behavior change. The real content is (a) the 1.0.0 stability commitment and (b) the breaking dependency-floor change.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, focused open-source adapter that lets our messaging code stay the same while the underlying message broker can change. It just reached 1.0.0, which is the vendor's public commitment to a stable API — materially lower risk than depending on a 0.x library — and it is current with the newest Symfony and PHP releases rather than lagging. The business value is reduced lock-in: we can move between RabbitMQ, Redis, or a cloud queue without rewriting application code. The cost is one additional dependency and a compatibility check each time we upgrade our PHP framework. There is no new functionality in this release; the decision it enables is whether we standardize our asynchronous messaging on this abstraction.

For engineering (the working summary): 1.0.0 adds Symfony 8 support and drops EOL Symfony versions. Treat it as a breaking change to our dependency constraints, not to the public API — expect composer.json floor changes and possible cascading bumps across the enqueue/* tree. Proposed sequence: (1) read the new constraints in composer.json and confirm they fit our supported PHP/Symfony matrix; (2) branch the upgrade with the full test suite plus a smoke test that publishes and consumes a message through each transport we actually use in production; (3) confirm the failure-transport and retry behavior is unchanged, since that is the code path least likely to be covered by unit tests; (4) pin the version and document the minimum Symfony/PHP pair in the ADR. The php-cs-fixer change is CI-only and needs no action beyond a formatting pass.

Standing caveat to carry into any pitch: for Laravel-first teams, frame this as an option for a specific Symfony-Messenger-based service, never as a queue upgrade for the Laravel estate. Overstating the Laravel fit is the most likely way this recommendation gets rejected in review.