Messenger Mailer Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for asynchronous, attachment-bearing email. The only genuinely hard problem here is the boundary between the request cycle and the queue worker: a generated PDF invoice, CSV export, or uploaded file is a temp path that no longer exists when the worker picks up the message minutes later. This package exists to make that handoff safe. The buy decision should be framed as "do we pay a dependency for ~200 lines of attachment lifecycle code, or own it?"
• Latency and reliability roadmap for transactional mail. Moving send off the request path removes third-party SMTP latency from user-facing response times and gives you free retries, backoff, and failure isolation via Messenger transports — a real, measurable win on checkout, signup, and reporting flows.
• Framework standardization decision. This is a Symfony bundle, not Laravel. That single fact likely resolves the decision: if the estate is Laravel, this is out of scope — Laravel's queued Mailables already cover async + attachments natively, and adopting this would mean importing a second mail abstraction and Messenger runtime for no benefit.
• Use-case triage. Strong fits: order confirmations with generated PDFs, scheduled report distribution, bulk/export emails, invoice delivery. Weak fits: marketing email, templating/layout systems, deliverability, open/click tracking — none of which this addresses.
• Dependency-risk posture. 6 stars, 0 dependents, single maintainer, low opportunity score. This is a vendor-the-code candidate, not a strategic platform bet. Treat adoption as "we are taking on a small piece of upstream code we may have to maintain ourselves," not "we are integrating with a supported product."

When to Consider This Package

Adopt when all of the following hold:

• The application is Symfony and already runs symfony/messenger and symfony/mailer in production. This bundle is an integration layer, not a standalone mailer — without both, it adds nothing.
• You have a concrete flow where attachments are produced dynamically (generated PDFs, exports, user uploads) and the send must be async. This is the narrow window where it earns its place; static or inline assets don't need it.
• The team values a small, MIT-licensed, single-purpose dependency over ~a day of internal implementation and test coverage.
• You are comfortable pinning a version and accepting that upstream fixes may never arrive.

Look elsewhere when:

• You are on Laravel. Queued Mailables with attachData()/attach() already solve this. Adopting a Symfony Messenger bundle here is a net negative.
• Symfonfy's native path already suffices — MailerInterface dispatches SendEmailMessage through Messenger out of the box, and Email handles attachments. If your attachments are static or stored on durable storage (S3 paths, DB blobs) before dispatch, you may need nothing extra at all.
• You need capabilities above the transport layer: templating systems, marketing automation, deliverability, bounce handling, analytics, multi-tenant sending domains. Buy a sending platform, not a bundle.
• Your risk tolerance for unmaintained dependencies is low, or your security/compliance review requires an actively maintained dependency with a support path.
• High-volume or SLA-bound mail where you need observability, rate limiting, and provider failover baked in.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free, open-source component that lets us send emails with generated attachments — invoices, reports, exports — in the background instead of during the customer's request. The business value is speed and reliability: pages respond faster, and failed emails retry automatically instead of vanishing. The cost is near zero, but so is the support: it's a tiny project with almost no adoption, so we should expect to own the code ourselves. Recommendation: treat it as a reference implementation or a pinned, vendored dependency — not a strategic platform choice — and only if we're a Symfony shop.

To engineering (the honest version): The problem is real — attachment temp files die before queue workers consume the message. But before adding a dependency, confirm our Symfony version doesn't already cover this via Mailer + Messenger, and confirm whether our attachment source is durable (object storage / DB) rather than a request-scoped temp path. If it is durable, we may need nothing. If it isn't, this bundle is a reasonable ~200-line shortcut, with the caveat that we pin the version, write our own integration tests around the serialization/cleanup path, and accept that we're effectively forking it.

The one-line decision rule: Symfony shop with dynamic attachments on an async mail path → evaluate and likely vendor it. Laravel shop, or static/durable attachments → skip.