- Is invis1ble/messenger-bundle a Laravel package?
- No. It is a Symfony bundle, not a Laravel package. It depends on Symfony's Bundle class, service container, autoconfiguration tags, and compiler passes, none of which Laravel provides. Using it in a Laravel-primary stack means adding a second bus abstraction and a translation layer.
- Can I use invis1ble/messenger-bundle in a Laravel application?
- Only with material caveats. The viable paths are to extract the interfaces rather than install the bundle, or to run it as a Symfony service alongside Laravel. Its scope overlaps with Illuminate\Contracts\Bus\Dispatcher, ShouldQueue, job middleware, and Illuminate\Bus\Batch. For a Laravel-primary stack, native Laravel bus features are simpler and better supported.
- What Laravel versions does invis1ble/messenger-bundle support?
- It does not declare Laravel version support. The documented matrix is Symfony ^6.4 || ^7.0 || ^8.0, with PHP 8.2+ on Symfony 6.4 and 7.x, PHP 8.4+ on Symfony 8.0, and PHP 8.4.1+ on Symfony 8.1. There is no Laravel integration target.
- How do I install invis1ble/messenger-bundle?
- You install it with Composer, but registration assumes a Symfony kernel and service container, not Laravel's provider system. The v6.2.0 release documents a --with-all-dependencies semver-constrained upgrade path. In a Laravel app you would still need to bridge Symfony bundle wiring yourself.
- What does invis1ble/messenger-bundle v6.2.0 change for Symfony 8?
- The headline capability is Symfony 8 kernel support. It is validated by real-kernel tests for lint:container, autowired aliases, and service IDs. That reinforces coupling to Symfony's container and kernel lifecycle rather than loosening it. Public bus interfaces and service IDs are unchanged.
- Is invis1ble/messenger-bundle production-ready?
- Technical risk is moderate-high. CI coverage and real-kernel tests are credible positives, but there is no adoption evidence, no downstream consumers, and zero stars or dependents. There is also no security or deprecation policy and no CVE disclosure process. MIT licensing is the one unambiguous positive.
- What are alternatives to invis1ble/messenger-bundle for Laravel?
- Laravel's native bus is the obvious alternative: Illuminate\Contracts\Bus\Dispatcher, ShouldQueue, job middleware, and Illuminate\Bus\Batch. For Symfony applications, Symfony Messenger is the direct alternative. Because this bundle overlaps with Laravel contracts, adding it usually increases complexity instead of reducing it.
- How is invis1ble/messenger-bundle tested?
- CI runs a matrix across Symfony 6.4, 7.4, 8.0, and 8.1 on PHP 8.2, 8.4, and 8.5, with composer test, composer lint, and composer check targets. Real-kernel tests cover handler isolation, commands, query results, async event delivery, and traceable buses. Those kernel-level tests are the kind most likely to catch container-boot regressions.
- What is the dependency chain for invis1ble/messenger-bundle?
- The bundle pins invis1ble/messenger ^5.1, a second versioned artifact in the same maintainer namespace. That creates a coupled upgrade cadence across two packages. The release notes do not clarify whether the two are maintained in lockstep or whether the dependency carries its own support commitment.
- Should I extract the interfaces instead of installing invis1ble/messenger-bundle?
- Extraction is no more tractable in v6.2.0. The release notes describe the deliverable in kernel terms such as autowired aliases, lint:container, and service IDs, all of which are bundle-scoped wiring. Vendoring the abstraction forfeits exactly what the bundle spends its effort hardening. If you need framework-agnostic contracts for Laravel, prefer Laravel's native bus contracts.