Pbjx Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the messaging layer. The core decision this package informs is whether to hand-roll command/event/request buses and transport plumbing or adopt an existing schema-driven stack. gdbots/pbjx-bundle is a thin Symfony DI integration over gdbots/pbjx, so the real question is "do we buy into the PBJ/PBJX model" rather than "do we add this bundle."
• Contract-first vs. code-first events. PBJ is schema-first: messages are defined in a schema language and compiled to PHP classes, which forces an explicit conversation about schema ownership, versioning, and backwards compatibility before services ship. That is a product/architecture decision (who owns the event catalog, how do we evolve it) that a plain Laravel event class does not force.
• Transport strategy. Because the bundle wires buses to a configurable transport (in-memory for tests, NATS/queue-backed for production), it lets you defer the broker decision and swap it later without rewriting handlers. Useful when the roadmap says "async eventually" but the broker isn't chosen.
• Event-driven roadmap sequencing. Adopting it early sets the shape of later features (outbox, replay, cross-service consumers, projections). Adopting it late is a rewrite. This is a "decide now, cheaply, or pay later" item.
• Standardization across services. If more than one PHP service is planned, this is a lever for a single message contract across them — but only if the whole fleet is Symfony/PHP.
• Platform currency as a gating decision. v5.0.0 requires Symfony 8.x and PHP 8.5+. That converts an ordinary dependency choice into a platform-upgrade decision: adopting this bundle means the host service must already be (or move to) the newest Symfony major and a brand-new PHP minor. If the roadmap has the platform on Symfony 6.4/7.x LTS or PHP 8.2–8.4, the package is not a drop-in — the platform upgrade becomes part of the cost, and the upgrade must be sold on its own merits.
• Not supported: framework choice. Despite the "Laravel/PHP package" framing, this is a Symfony bundle (Symfony\Bundle\FrameworkBundle-style extension, service definitions, bundle registration). It will not boot in Laravel. A Laravel decision would be "use gdbots/pbjx directly and hand-wire service providers," which is a meaningfully larger build.

When to Consider This Package

Consider it only when most of these hold:

• The application is Symfony (not Laravel), and the team is already comfortable with bundle/DI configuration.
• The application is on, or about to move to, Symfony 8.x with PHP 8.5+. v5.0.0 hard-requires both; anything older needs a platform upgrade first or a pinned v4.x line.
• You are already in, or deliberately committing to, the gdbots ecosystem — you use or plan to use gdbots/pbj schemas and the PBJ compiler toolchain.
• You need command, event, and request buses with a swappable transport, and you want the wiring conventions decided for you.
• Your team is small enough to read the source as primary documentation, and can pin versions and carry a fork if needed.
• You have a concrete cross-service or event-sourcing use case, not just "we might need events someday."

Look elsewhere when:

• Laravel is the stack. Use Laravel's native events/queues/broadcasting, or evaluate Symfony Messenger, EventSauce, Ecotone, or Prooph. Wiring PBJX by hand into Laravel's container is possible but you lose the only thing this package actually provides.
• You are on Symfony ≤7.x or PHP <8.5 and have no near-term platform upgrade funded. The v5 line leaves you behind on the newest major; staying on v4.x means pinning an older line and forgoing fixes.
• You need external validation, community support, or an SLA. Zero stars, zero dependents, and a single-vendor release cadence mean there is no ecosystem to fall back on. Budget for "we own this."
• You need broad broker coverage or managed-cloud integrations. Verify the transport you need exists in gdbots/pbjx before committing; the bundle won't add it.
• The scope is a single app with in-process events. The schema/codegen overhead is not repaid.
• You can't adopt the PBJ schema toolchain — the bundle is not useful without generated message classes.

Health signal to weigh explicitly: the v5.0.0 breaking release (2026-01-16) confirms active maintenance, but it also tells you the project's policy is to track the leading edge of Symfony and PHP with major-version jumps and no parallel LTS branch. Expect to be forced onto new Symfony/PHP majors on their schedule, not yours, and to absorb breaking upgrades in a dependency with no community to help you debug them. Ask for reference deployments, confirm the release cadence isn't purely internal-driven, and ask what the support window is for the pre-8.x line.

How to Pitch It (Stakeholders)

For executives: This is a small, free (Apache-2.0) integration layer that sits on top of a schema-driven messaging library. It buys us a consistent, contract-first way for services to exchange commands and events, and it lets us change the underlying message broker later without rewriting business logic. The latest release (v5.0.0) also ties us to the newest Symfony 8 and PHP 8.5, so it only makes sense if our platform upgrade is already planned. The cost is not license fees — it's the learning curve of the PBJ schema toolchain, plus the fact that we become our own support team: no public community, no third-party dependents, and a single vendor whose release policy is to move quickly to new framework majors.

For engineering: It's a Symfony bundle; it registers PBJX buses, subscribers, and a transport into the container. In exchange for adopting PBJ schemas (codegen step in the build), you get typed, versioned messages and a transport abstraction. Note the v5.0.0 breaking change: Symfony 8.x and PHP 8.5+ are hard requirements, with no compatibility shim for 7.x — so the integration task starts with a platform upgrade, and the 4.x line becomes our pin if we can't do that now. It is not a Laravel package — on Laravel we'd use gdbots/pbjx directly and write the service provider ourselves, which roughly doubles the integration effort.

Recommendation to state plainly: Treat this as a strategic vendor bet, not a commodity dependency, and treat the v5.0.0 platform floor as an additional adoption gate. The scoring (low opportunity score, no dependents) argues against putting it on the core roadmap without a time-boxed spike. Approve a 1–2 week spike on a non-critical Symfony service that is already on Symfony 8 / PHP 8.5 — validating the schema toolchain, the transport we'd actually use, and the operational story — and decide build-vs-buy at the end of it. If the spike is skipped, or if the platform upgrade isn't independently justified, the default should be the framework-native option (Symfony Messenger or Laravel queues), not this bundle.