- Can I install face/commander-bundle in a Laravel application?
- No. face/commander-bundle ships a Symfony Bundle subclass, a DI extension, and likely a compiler pass, and all of that wiring depends on the Symfony kernel boot and compile phases. Laravel's container never runs those phases, so composer requiring this package into a Laravel app will not give you a working command bus. Use Illuminate\Contracts\Bus\Dispatcher instead.
- Is face/commander-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a Laravel package. Despite the Laravel/PHP framing in its description, the architecture is container-lifecycle-coupled to the Symfony kernel. If your target stack is Laravel, the framework fit is effectively none.
- How do I install and register face/commander-bundle?
- In a Symfony app you would composer require face/commander-bundle, enable the bundle in config/bundles.php, and configure its DI extension. There is no Laravel service provider, facade, or config publish step. Confirm the declared version constraints in composer.json before attempting an install.
- Which PHP and Symfony versions does face/commander-bundle support?
- Check composer.json in the repository, because the package shows no supported-version matrix. The signals suggest a PHP 5.x/7.x-era codebase that is likely incompatible with PHP 8.2+ and Symfony 6/7. Treat modern-version support as unverified until you read the constraints yourself.
- What is the Laravel equivalent of face/commander-bundle?
- Laravel's native bus: Illuminate\Contracts\Bus\Dispatcher, the dispatch() helper, ShouldQueue for async work, and job middleware for cross-cutting concerns. These are maintained, documented, and cover retries and failure handling that this bundle almost certainly lacks. For Symfony the equivalent is Symfony Messenger with command.bus and query.bus.
- How does face/commander-bundle register and resolve command handlers?
- Based on the bundle shape, an internal DI extension plus a compiler pass tags handler services and maps command FQCNs to handlers, with a dispatcher facade resolving them through the container. The exact strategy (service ID equals FQCN, tagged services, or explicit registration) must be confirmed in the source. Whatever it is, it depends on Symfony's container compilation, which Laravel does not perform.
- Does face/commander-bundle support async dispatch, queues, or middleware?
- There is no evidence of a queue or transport abstraction, middleware hooks, retries, or a failure transport. Assume synchronous dispatch only. Symfony Messenger and Laravel queues both provide these features as first-party, maintained solutions.
- Is face/commander-bundle actively maintained and safe for production?
- No. The repository has 0 stars, 0 dependents, a single author, and an overall score around 0.03, with no evidence of CI, tests, a security policy, or a support matrix. Adopting it means owning an unmaintained dependency with no upstream triage. Confirm the license and archival status before any use.
- Should I fork face/commander-bundle to adapt it for Laravel?
- Not recommended. The functional value is roughly 100 to 200 lines of glue: a command-to-handler map plus a dispatcher facade. Reimplementing that as a Laravel service provider, or a Symfony tagged-service compiler pass, is cheaper and lower-risk than maintaining a fork with no upstream to rebase against.
- How do I test or migrate away from face/commander-bundle?
- Adopt the pattern, not the package: define your own CommandBus interface with a dispatch(object $command): mixed method, back it with Laravel's dispatcher, and keep domain code depending only on the interface and command/handler classes. That makes any future transport swap a one-file change. Test the bus by asserting handlers receive the expected command and that unregistered commands raise a typed exception.