Weave Code
Symfony Messenger Polyfill Laravel Package
lendable/symfony-messenger-polyfill
A lightweight polyfill that provides Symfony Messenger-compatible classes and interfaces, letting Laravel and PHP projects use Messenger-style message buses without requiring the full Symfony component. Useful for package authors who need interoperability while keeping dependencies minimal.
lendable/symfony-messenger-polyfill provides a lightweight implementation of the Symfony Messenger contracts, letting you use standard MessageBusInterface and related interfaces without pulling in the full framework component. It is aimed at libraries and applications that want to stay decoupled from Symfony while remaining compatible with Messenger-style message handling.
- Drop-in MessageBusInterface implementation for dispatching messages
- Minimal dependency footprint—ideal for framework-agnostic packages
- PSR-compatible, easy to swap for a real Messenger bus later
- Simple API that mirrors Symfony conventions
Frequently asked questions about Symfony Messenger Polyfill
- What is lendable/symfony-messenger-polyfill?
- It is a Composer package that backports the Symfony Messenger 4.2 API surface, including message bus, envelopes, middleware, and transports, onto Symfony 3.4, 4.0, and 4.1. It exists so teams could adopt Messenger contracts before upgrading Symfony. It assumes Symfony's dependency injection container, console, and event dispatcher, and it is not a Laravel package.
- Does this package work with Laravel?
- No. There is no Laravel service provider, queue driver, or Horizon integration, and it presumes Symfony's DI container and console. Laravel already solves this problem with Illuminate\Bus, queued jobs, batching, failed_jobs, and Horizon. Using this package in Laravel means running a second, parallel bus with separate retry and failure handling.
- Which Symfony versions does this polyfill support?
- It targets Symfony 3.4, 4.0, and 4.1, polyfilling the Messenger API that shipped in Symfony 4.2. It is not a runtime replacement, so it does not include the bugfixes, transport hardening, or security patches from later 4.2 and 4.3 releases. It has no support for Symfony 5, 6, or 7.
- Can I install lendable/symfony-messenger-polyfill on PHP 8 or Symfony 5+?
- Expect hard Composer conflicts. Its dependency constraints are frozen in the 2019 PHP and Symfony era, so modern PHP 8.1+ and any current Symfony LTS will usually fail resolution. Because the repository is archived, there is no upstream path to widen those constraints; only a fork can change them.
- Is lendable/symfony-messenger-polyfill abandoned or maintained?
- It is archived and has not been maintained since early 2019. There is no security response process, no PHP 8 support, and no Symfony 5, 6, or 7 support. It also has very few stars and zero dependents, so there is little production validation and no community to ask about real failure modes.
- How do I install lendable/symfony-messenger-polyfill with Composer?
- Run composer require lendable/symfony-messenger-polyfill in a project already pinned to Symfony 3.4, 4.0, or 4.1 and a compatible PHP version. The package is MIT licensed and PSR-4 autoloaded, so installation itself is mechanically simple. The real constraint is your existing dependency graph, not the install step.
- Is this Symfony Messenger polyfill safe for production?
- Technical risk is high. The package is archived, receives no security patches, and only shims the API rather than the runtime, so it cannot deliver fixes that landed in later Messenger releases. Envelope serialization may also diverge from current Messenger, which makes cross-version message replay fragile. Treat it as a historical artifact, not a production dependency.
- What alternatives should I use instead of this polyfill in Laravel?
- Use Laravel's native Illuminate\Bus with queued jobs, job batching, the failed_jobs table, and Horizon for supervision. That is the lowest-risk option and requires no new dependency. If you are on Symfony instead, upgrade to a supported LTS such as 6.4 or 7.x and use native Messenger.
- What Messenger features does this polyfill actually provide?
- It backports the Messenger 4.2 API surface: the message bus, envelope and stamp concepts, middleware, and transport abstractions. It does not deliver the underlying runtime improvements, transport hardening, or failed-message handling refinements added in later Symfony releases. Semantics can therefore differ from what current Messenger documentation describes.
- Should I fork this package or migrate off it?
- Migration is the correct path. Inventory your dispatch points, then map them to Illuminate\Bus in Laravel or upgrade Symfony and use native Messenger. Only if a Symfony upgrade is genuinely blocked should you vendor the polyfill under an internal namespace, pin constraints, name a maintainer, and record a sunset date in your risk register.
Weaver
How can I help you explore Laravel packages today?