- Can I use gdbots/pbjx-bundle in a Laravel application?
- No. It is a Symfony bundle that depends on bundle classes, an extension config tree, tagged-service collection and compiler passes, none of which Laravel provides. Laravel's framework dependencies resolve against Symfony 7.x components, so a Composer require of v5 fails dependency resolution outright rather than needing a shim. If you genuinely need PBJX capabilities inside a Laravel product, run it as a Symfony sidecar service and cross the boundary over HTTP or a queue.
- How do I install gdbots/pbjx-bundle?
- Install it with Composer, register the bundle in config/bundles.php, and configure the PBJX services through the bundle's configuration tree. You also need gdbots/pbjx for the messaging engine and gdbots/pbj for the message contracts, since the bundle is only the Symfony wiring layer. On v5 you must already be on Symfony 8 and PHP 8.5 or newer before Composer will resolve the install.
- What Symfony and PHP versions does gdbots/pbjx-bundle v5 require?
- Version 5.0.0 requires Symfony 8.x and PHP 8.5 or newer. That release is a pure version-floor jump with no new features, no deprecations and no migration shims. If you are on Symfony 6 or 7 you must pin to the v4.x line, which is now a legacy branch of undocumented support duration.
- What does gdbots/pbjx-bundle actually do?
- It is the dependency-injection glue that registers PBJX command, event and request buses, service locators and tagged handler discovery inside a Symfony container. It supplies the bundle class, the extension config tree and the compiler passes that wire handlers into the correct bus. The messaging engine itself lives in gdbots/pbjx, and the message contracts are generated from .proto schemas via gdbots/pbj.
- Is gdbots/pbjx-bundle actively maintained?
- Development is active in the sense that v5 shipped onto Symfony 8 and PHP 8.5 on release week, but there is no published LTS or support-duration policy. The v4.x line is the only viable branch for Symfony 6 and 7 hosts, and its long-term support is unknown. With zero stars, zero dependents and a single vendor org there is no community validation, no third-party tutorials and no Stack Overflow corpus to fall back on.
- How are command and event handlers discovered in this bundle?
- Handlers are registered through Symfony's tagged-service collection and compiler passes, so you tag your handler services and the bundle wires them into the appropriate bus at container compile time. This is exactly why the package cannot be ported to a generic PSR-11 container: tagging and compilation are the mechanism, not incidental detail. The trade-off is that debugging routes through a compiled third-party container you did not write, which is slow and opaque.
- What are the alternatives to gdbots/pbjx-bundle for a Laravel app?
- There is no drop-in Laravel equivalent. The realistic options are a Symfony sidecar that owns the PBJX buses with HTTP or a queue at the boundary, or a native reimplementation of just the command and event bus plus the Protobuf contracts you actually use. For conventional CRUD or plain queue jobs, Laravel's own event system and queue are a far better fit than a schema-first CQRS stack.
- Is gdbots/pbjx-bundle safe to run in production?
- The risks are operational rather than code quality. PHP 8.5 must exist in your base images, CI runners, developer machines and any managed or PaaS host, and managed platforms typically lag new PHP minors by quarters. You also inherit Symfony 8 ecosystem immaturity, so third-party bundles and transports you depend on need to be Symfony-8-ready. The Apache-2.0 licence gives you the right to fork but not a roadmap.
- Does the v5.0.0 release break existing Symfony 6 or 7 applications?
- Yes, completely and deliberately. It moves the package to Symfony 8 and PHP 8.5 with no features, deprecations or migration shims, so every existing Symfony 6 and 7 deployment is invalidated on upgrade. You can stay on v4.x, but you are then depending on a legacy branch with no stated support window.
- Do I need Protobuf schemas to use gdbots/pbjx-bundle?
- Yes. The bundle configures messaging around message classes defined in gdbots/pbj and generated from .proto schemas, so schema-first design is a prerequisite rather than an option. The bundle cannot protect you from breaking a message contract; schema evolution discipline stays with your team. If your domain is straightforward CRUD, that investment is almost certainly unjustified.