Mailer Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — it wraps Twig rendering and SwiftMailer transport into a mailer service. Before anything else, treat that mismatch as the headline finding.

Minimal steps to evaluate it:

1. composer require polifonic/mailer-bundle in a Symfony app (not Laravel).
2. Register the bundle — AppKernel::registerBundles() on Symfony ≤4, config/bundles.php on Symfony 5+.
3. Configure transport (swiftmailer: block) and point the bundle's template path at your Twig mail directory.
4. Read the bundle's Resources/config/services.* first — that's where the service ID and constructor arguments live, and it's the only reliable API documentation you'll get for a 1-star repo.
5. First use case: inject the mailer service into a controller and send one rendered transactional email (welcome, receipt, password reset) from a Twig template with a shared layout.

For a Laravel developer, the honest first step is: don't install this. The Laravel equivalent is already in core:

Mail::to($user)->send(new WelcomeMail($user));

with WelcomeMail implementing Mailable, ->view('emails.welcome'), and a Blade layout. Everything the bundle does (template + transport) is a Mailable plus config/mail.php.

Implementation Patterns

The patterns worth learning from the bundle, even if you never use it:

• Template-bound message objects. The bundle separates "render a Twig template with context" from "hand it to a transport." Mirror that in Laravel with a Mailable per email type and $this->view(...)->with([...]) in the constructor — never build mail bodies inline in controllers.
• Shared layout via inheritance. Twig {% extends %} for the shell (header, footer, unsubscribe) is the direct ancestor of Blade's <x-mail::layout> / @extends('emails.layout'). Copy the convention, not the code.
• Config-driven transport. Swapping SMTP ↔ spool/file from config is MAIL_MAILER=log|smtp|array in Laravel. Use log locally, array in tests, smtp in prod.
• Service injection over facades. Symfony injects the mailer into a command or listener; Laravel's Mail facade is fine, but injecting Illuminate\Contracts\Mail\Mailer keeps mailables testable and queue-safe.
• Queue/async boundary. The bundle sends synchronously unless you wire a spool. In Laravel, make the mailable ShouldQueue for anything triggered by a user request.
• Porting checklist if you must migrate off it: Twig → Blade syntax ({{ }} is compatible; {% %} → @if/@foreach), swiftmailer config → mail.php, service wiring → Mailable classes, spool → queue + Mail::fake() in tests.

Gotchas and Tips

• SwiftMailer is end-of-life. It was deprecated in favor of Symfony Mailer in Nov 2021. Any bundle built on it is frozen on old PHP/Symfony versions and receives no security fixes. That alone disqualifies it for new work.
• 1 star, 0 dependents. No community, no issue triage, no release cadence, no security disclosure process. Treat the source as a reference implementation, not a dependency. If you genuinely need it, vendor it into your repo and own it.
• Symfony version drift. Bundle registration and config key names changed between Symfony 3, 4, and 5+. Expect to edit services.yml yourself.
• Twig escaping in HTML email. {{ var }} autoescapes — fine for text, but if you're injecting pre-rendered HTML you need |raw, which is XSS-adjacent. Prefer passing scalars and letting the template compose.
• No asset() in email. Absolute URLs only; inline your CSS (email clients strip <style> in ways that vary). The bundle won't help with either.
• Sync sends block the request. Without a spool, a slow SMTP host stalls the web response. In Laravel this is why ShouldQueue exists.
• Debugging: set transport to a file/spool and inspect the raw MIME before blaming the template. Mail::fake() + assertSent gives you the same visibility in Laravel without sending.
• Extension points (if you must extend it): override Twig templates via bundle inheritance, or decorate the mailer service rather than editing vendor code.
• Bottom line for a Laravel shop: harvest the design — one class per email, shared layout, transport from config, async by default — and implement it with Mailable, Blade, and config/mail.php. Adopting the bundle is a net negative.