Weave Code
Messenger Mailer Bundle Laravel Package
fusonic/messenger-mailer-bundle
Symfony bundle that bridges Mailer and Messenger, letting you dispatch emails as messages and send them asynchronously through your Messenger transport. Configure transports, queue mail instead of blocking requests, and keep email delivery reliable and decoupled from your application flow.
At a glance
Frequently asked questions about Messenger Mailer Bundle
- Can I use fusonic/messenger-mailer-bundle in a Laravel application?
- No. It is a Symfony bundle: it ships a Bundle class, service definitions consumed by Symfony's dependency injection container, and depends on FrameworkBundle kernel wiring for registration. Laravel has no Kernel::registerBundles() and never boots bundles, so Composer will install the package but nothing will execute. Laravel's queue primitives (jobs, ShouldQueue, Queue::push) are a parallel abstraction to Messenger transports and envelopes, not a compatible one. Use a queued Mailable instead.
- How do I install and configure fusonic/messenger-mailer-bundle in a Symfony app?
- Install it with Composer and let Symfony Flex register the bundle, or add it manually to config/bundles.php. You then configure a Mailer DSN and a Messenger transport (Doctrine, AMQP, Redis, or similar), and route the bundle's email message class to that transport under framework.messenger.routing. Run a worker with bin/console messenger:consume on the configured transport so messages are actually sent. Because the bundle dispatches messages rather than sending inline, nothing leaves your app until a worker consumes the queue.
- Why does serializing a Symfony Email with attachments break Messenger?
- Email objects contain DataPart instances backed by PHP streams, and those streams do not serialize cleanly when the message is pushed onto a transport. Symfony's native Mailer plus Messenger bridge serializes the whole Email onto the transport, which is exactly where attachment handling fails. This bundle works around it by persisting the binary attachment to storage, enqueueing a lightweight message that references it, and rehydrating the file at send time. That indirection is the bundle's entire reason to exist.
- What is the Laravel equivalent of this bundle for queued emails with attachments?
- Laravel Mail already solves this natively. A Mailable implementing ShouldQueue, or Mail::queue(), serializes attachment paths rather than raw bytes, so the queued payload stays small and serialization never touches a stream. Inside the job you attach at send time with attachFromStorageDisk() or attach(). You get retries, backoff, and failure handling from the queue worker without adding a dependency.
- Which Symfony and PHP versions does fusonic/messenger-mailer-bundle support?
- The exact constraint range is not documented in the overview, so read composer.json in the repository before committing to it. That range is the first thing to verify against your host application, because it determines whether a Symfony minor upgrade will block the package. Symfony's major-version cadence (7.x to 8.x) will strand consumers who cannot fork and patch quickly. Pin and verify Symfony minors if you use it natively.
- Why should I avoid adding this package to a Laravel composer.json?
- There is no supported execution path. Making it work would require either booting Symfony's DI container inside Laravel, which is a permanent maintenance liability, or forking the bundle to strip the DI and kernel coupling and rebuild the storage, message, and handler triad against Laravel's queue. Both options are more work and more risk than writing the roughly 150 lines of the pattern directly. The incremental capability over Laravel's built-in queued Mailables is close to zero.
- How do I handle Messenger transport payload limits when email attachments are large?
- Never put the binary on the transport. Persist attachments to a dedicated disk (S3 or local) under a job-scoped path before dispatch, then enqueue a message carrying only the key plus metadata such as filename, MIME type, and size. This keeps you well under transport caps like SQS's 256 KB per message. Also set an explicit maximum attachment size in your application so oversized uploads fail fast rather than silently breaking the queue.
- How do I test that emails are dispatched asynchronously instead of sent inline?
- In Symfony, route the message to Messenger's in-memory or test transport during the test run, then assert the message was dispatched without sending anything. After handling the message explicitly, assert against the Mailer test transport to confirm the email and its attachments were built correctly. The two assertions are separate on purpose: one proves the queue handoff, the other proves the send. Do both, because a passing dispatch test alone will not catch a broken attachment rehydration step.
- Is fusonic/messenger-mailer-bundle actively maintained, and what is the bus factor?
- Adoption signals are weak: roughly six stars, zero dependents, and a single organizational maintainer, which makes it effectively a vendor-internal utility published publicly. There is no visible external contributor base, so the bus factor is one team. The MIT license is the one clean signal, meaning forking is legally unencumbered if you need to patch it yourself.
- What are the alternatives to this bundle for asynchronous email in Symfony?
- Symfony's Mailer component already integrates with Messenger, and for plain emails with no attachments that native bridge is sufficient. This bundle only adds value for the attachment persistence and rehydration case, so evaluate whether you actually hit serialization failures before adopting it. If you are designing a mixed Laravel and Symfony estate, adopt the pattern rather than the package: an AttachmentStore interface with put, get, and delete methods, a message DTO, and a handler. That keeps the seam explicit and swappable across both stacks.
Weaver
How can I help you explore Laravel packages today?