- What is micro-module/command-bus used for?
- It is a lightweight command bus for Laravel micro-module applications that dispatches command DTOs to their handlers through a middleware pipeline. Its purpose is to separate write operations from the HTTP/controller layer and to give independently versioned micro-module packages a shared way to dispatch commands without a direct dependency on each other. It targets modular monoliths and CQRS-lite designs rather than multi-service architectures.
- How do I install micro-module/command-bus?
- Installation is shaped as composer require micro-module/command-bus, followed by registering the package service provider for modular applications. The real blocker is dependency constraint resolution, because the latest release dates from 2021 and predates current Laravel and PHP versions. Test the install in a throwaway project before adding it to an existing application.
- Does micro-module/command-bus support Laravel 10 and Laravel 11?
- There is no published support matrix confirming Laravel 10 or 11 compatibility. The 2021-05-18 release predates Laravel 9, 10, and 11, so illuminate/support and illuminate/container are likely capped at ^7 or ^8. Treat it as incompatible with modern Laravel until you verify the composer.json constraints yourself.
- What happens if no handler is registered for a command?
- The available material does not confirm the behavior when a command has no registered handler, so it could be an exception, a no-op, or a silent null. This is a key question to close before adopting the package. Write a test for the missing-handler path in a scratch project and decide whether the failure mode is acceptable for your write operations.
- Does it support middleware for transactions and authorization?
- Yes, middleware support is a core part of the design, with a pipeline that lets you attach cross-cutting concerns such as transactions, authorization, logging, and idempotency. The open question is how cleanly that pipeline composes with Laravel's DB::transaction and your existing middleware conventions. Verify the composition seam before relying on it for transactional writes.
- Can commands be queued or dispatched asynchronously?
- Asynchronous transport is not confirmed for this package, so do not assume a ShouldQueue equivalent or a queue bridge exists. Laravel's native bus already covers ShouldQueue, Bus::chain, and Bus::batch out of the box. If background processing matters, that is a strong reason to stay on the framework dispatcher.
- How does it compare to Laravel's built-in command bus?
- Laravel already ships Illuminate\Contracts\Bus\Dispatcher, the dispatch() helper, pipeline middleware via the $pipeline array, and ShouldQueue support, all maintained by the framework. A third-party bus only justifies itself if it adds conventions such as naming standards, payload envelopes, result objects, or module routing. Otherwise it duplicates framework functionality with extra maintenance risk.
- Is micro-module/command-bus actively maintained and production ready?
- It has zero stars, zero dependents, and a single maintainer with no release since 2021, so there is no production validation to inherit. There is no issue history, no security advisory channel, and no published test coverage or CI status. You would be the first adopter and would absorb all discovery cost.
- Does it work with PHP 8.1+ and modern Composer dependency resolution?
- The release timeline predates mainstream PHP 8.1, so expect constraint failures when installing into a current application. Workarounds such as --ignore-platform-reqs, replace directives, or a fork are red flags rather than safe fixes. Prefer a package whose constraints honestly support the PHP and Laravel versions you run.
- What are the alternatives for cross-module command contracts in Laravel?
- Use Laravel's native bus for dispatch mechanics, middleware, and queued transport. If you genuinely need cross-module contracts, publish a small internal interfaces package that you control and keep the bus behind a wrapper such as App\Contracts\CommandBus so the package interfaces never leak into domain code. That gives you the decoupling without adopting an unmaintained dependency.