Bernard Bundle Bridge Laravel Package

Product Decisions This Supports

• Legacy async command handling triage. The only real decision this package informs is what to do with an existing Symfony 2.x/3.x application that already dispatches SimpleBus commands to Bernard queues. It is glue, not capability: it lets SimpleBus/AsynchronousBundle hand serialized commands to BernardBundle and lets workers consume them. That makes it a migration scoping input, not a feature enabler.
• Build vs. buy vs. own. The bridge is thin — a service wiring a command serializer to a producer, and a consumer that feeds a message back into the command bus. A PM reading this package should conclude that the "bridge" layer is a few hundred lines of glue you could own in-house, rather than a dependency you inherit.
• Framework consolidation roadmap. The existence of this package is a useful artifact for the "why migrate to Symfony Messenger" conversation: Messenger (stable since Symfony 4.1) subsumes Bernard as transport, subsumes AsynchronousBundle as middleware/worker model, and removes the need for a third-party glue package entirely. Every capability offered here has a first-party equivalent.
• Pattern validation, not code adoption. It documents the standard shape of async CQRS in PHP — command bus → serialize → transport → worker → bus — which is useful when writing internal architecture guidance or evaluating vendored alternatives (Laravel queues, Enqueue, Messenger).
• What it does not support: no roadmap item, no customer-facing feature, no scalability story that isn't better served by a maintained transport. With 2 stars, zero dependents, no release since 2017, and an archived repo, it carries no community signal to anchor a decision on.

When to Consider This Package

Consider it only under a narrow, time-boxed set of conditions:

• You are on a Symfony 2.8/3.x application that already runs SimpleBus/AsynchronousBundle and BernardBundle in production.
• You have an immediate need for async command dispatch and no budget or window to migrate transports this quarter.
• Your PHP runtime and dependency graph are already pinned to that era, so no transitive upgrades are blocked.
• You accept that you are adopting an archived, unmaintained artifact — you will own patching, security triage, and compatibility with any future dependency bump.

Look elsewhere when any of the following is true:

• Greenfield or Symfony 4.4+ — use Symfony Messenger with Doctrine, Redis, or AMQP transport. It is maintained, first-party, and covers retries, failure transport, middleware, and worker consumption.

• Laravel context — the native queue + job system, or laravel/framework

  Bus/Queue primitives, already provide command-to-queue dispatch without a bridge package.

• You need support, CVE response, or a maintainer to talk to. None exist here.

• You need modern transport features — delayed dispatch beyond what Bernard exposed, per-transport failure queues, message deduplication, observability hooks.

• Supply-chain review applies. An archived repo with 2 stars and 0 dependents is a review flag, not a shortcut.

How to Pitch It (Stakeholders)

To executives: This package is not something we should build on. It is a small adapter that connects two PHP libraries — a command bus and a message-queue abstraction — both of which have been superseded by functionality now shipped inside Symfony itself. It was last released in 2017, the repository is archived, and no other public project depends on it. The business risk is straightforward: unmaintained code receiving no security patches, with no one to escalate to. The business opportunity is also straightforward: the migration target (Symfony Messenger) is first-party, maintained, and removes an entire class of glue dependency. Recommendation: do not adopt; treat any existing use as migration debt with a named owner and a scheduled exit.

To engineering: Treat this as a reference implementation, not a dependency. It shows the contract between an asynchronous command bus and a queue transport, and that contract is now native to Messenger middleware and transport configuration. If we are on SimpleBus + Bernard today, we can replicate the effective behaviour of this bridge ourselves in well under a day of work, which removes the archived dependency immediately while a full Messenger migration is scoped. If we are starting anything new, this package is out of scope by default — no exceptions without an explicit time-boxed waiver tied to a legacy system.

Framing for the decision record: the choice is not "adopt this package or not," it is "own ~200 lines of glue we control, or own an abandoned dependency we don't." The former is cheaper on every axis.