- Is lmc/cqrs-bundle a Laravel package?
- No. lmc/cqrs-bundle is a Symfony bundle, not a Laravel package. Its value is tied to Symfony bundle registration, dependency-injection extension loading, compiler passes, and DI service tagging, none of which exist in Laravel's container. The portable part is the underlying lmc/cqrs library, which you would wire into Laravel yourself.
- How do I install lmc/cqrs-bundle in a Laravel application?
- Do not install the bundle as your integration path. In Laravel 11 or 12, Composer will usually fail because lmc/cqrs-bundle 2.0.0 supports Symfony 6 while the framework pulls Symfony 7 components. Install lmc/cqrs:^2.0 as a library instead, bind its buses behind your own CommandBus and QueryBus interfaces, and register handlers in a hand-written Laravel service provider.
- Does lmc/cqrs-bundle support Laravel 10, 11, and 12?
- There is no official Laravel support. The underlying library's PHP >=8.1 requirement is compatible with Laravel 10, 11, and 12 on PHP 8.2 or 8.3, but the bundle's Symfony 6 ceiling conflicts with Symfony 7 components used by Laravel 11 and 12. A Composer dry-run against your exact Laravel version is the fastest way to confirm whether anything resolves.
- Why does Composer conflict with symfony/* ^7 when installing lmc/cqrs-bundle?
- lmc/cqrs-bundle 2.0.0 declares support for Symfony 6 but stops there. Laravel 11 and 12 pull Symfony 7 components transitively, so a symfony/*: ^7 requirement in the framework is a hard Composer conflict. This is the single cheapest integration test to run before committing to the package.
- Can I use lmc/cqrs-bundle without Symfony?
- Not as a bundle, because its auto-wiring depends on Symfony's DI container and compiler passes. You can use lmc/cqrs, the underlying framework-agnostic library, which provides handler lookup and middleware without event sourcing. In Laravel that means implementing your own handler registration, middleware pipeline, and transaction boundaries.
- Does lmc/cqrs-bundle support asynchronous commands or queues?
- No. Commands and queries stay synchronous and in-process, with no queue transport, retries, or async dispatch built in. Version 2.0.0 does not add an async story. If you need background processing, you must build it with Laravel queues or another transport around the bus.
- How do I test commands and queries if I adopt lmc/cqrs in Laravel?
- You can unit test handlers as plain PHP classes and bind a fake or real bus behind your own interfaces. There are no Laravel-specific testing helpers, and the Symfony bundle wiring will not load in Laravel. Keep middleware ordering and transaction boundaries explicit in tests because lmc/cqrs does not enforce them. Handler-not-found behavior is also a convention you should test directly.
- Is lmc/cqrs-bundle actively maintained?
- The last release is 2.0.0, dated 2022-05-06, and there has been no follow-up since. It has roughly 1 star and 0 dependents, so there is little community usage or third-party fixing. A backward-incompatible major release followed by silence fits the classic abandonment pattern. Treat it as dormant and be prepared to pin or fork.
- How does handler discovery work for lmc/cqrs in a Laravel app?
- In Symfony, the bundle discovers handlers through DI service tags and compiler passes. Laravel has no equivalent bundle system, so you must register handlers in a service provider and map each command or query class to its handler yourself. Handler-not-found behavior, middleware ordering, and transaction boundaries remain unenforced conventions. That hand-wiring is the main integration work when using the lmc/cqrs library.
- What are the alternatives to lmc/cqrs-bundle for CQRS in Laravel?
- Consider Symfony Messenger, which is maintained, framework-agnostic, and bridgeable into Laravel, or a small in-house CommandBus and QueryBus. Laravel's own bus and action classes cover many teams that only need a command bus plus action classes rather than full CQRS. Most Laravel codebases should evaluate those options before pinning a dormant Symfony bundle.