Mailer Bundle Laravel Package

Getting Started

First, calibrate your expectations: this is a Symfony bundle, not a Laravel package. If you're working in a Laravel app, there is no service provider, no facade, and no config publishing workflow here — you would be running it inside a Symfony kernel (or a standalone Symfony Mailer setup), not artisan. Treat it as a Symfony component you happen to be evaluating from a Laravel seat.

Minimal steps:

1. Read the repo README before anything else. With 2 stars and 0 dependents, the README and src/ are your only reliable documentation. Open DependencyInjection/ first — the extension class tells you the exact config key (likely wandi_mailer), the available options, and which services get registered. That one file is worth more than any guess about the API.
2. Check composer.json for the required PHP version, symfony/* constraints, and whether it pulls in symfony/mailer or swiftmailer. This determines your framework baseline and whether the bundle is even installable on your current Symfony LTS.
3. Install in a scratch Symfony app, not production: composer require wandi/mailer-bundle, then register the bundle in config/bundles.php and drop a minimal config/packages/wandi_mailer.yaml.
4. First use case to validate: send a single plain-text email through the bundle's mailer service and confirm it lands. If the bundle wraps Symfony Mailer, set MAILER_DSN (or the bundle's transport config) to something observable — Mailpit/Mailtrap locally, not a real SMTP server — so you can verify delivery without spamming.

The whole "getting started" phase here is really a feasibility spike: confirm the bundle installs, boots, and sends. Don't build architecture until that spike passes.

Implementation Patterns

Assuming the bundle exposes a mailer service (verify the service ID in Resources/config/services.* or config/services.yaml inside the bundle):

• Constructor injection over container pulls. Inject the bundle's mailer interface into your own application service and keep it behind your own thin port (App\Mail\Mailer). If the bundle is abandoned later, you rewrite one adapter class instead of grepping for $container->get(...).
• Configure once, inject everywhere. Put transport credentials in .env (MAILER_DSN and any bundle-specific env vars) and keep the YAML config environment-specific. Don't hardcode senders or hostnames in the bundle config — the sender address almost always differs per environment.
• Treat it as the transport layer, not the template layer. Compose your email body with Twig (or your own renderer) and hand the finished content to the bundle's mailer. This keeps you portable if you swap the bundle out.
• Async by default where the bundle allows it. If the bundle's mailer dispatches through Symfony Messenger or can be wrapped in a message handler, route sends through a queue. Synchronous SMTP in a request cycle is the classic source of slow checkout pages and 500s when the relay hiccups.
• Testing pattern: swap the transport for a null/in-memory transport in config/packages/test/ (or use Symfony's MailerAssertionsTrait if the bundle delegates to symfony/mailer). Assert on the message your service produces, not on the bundle internals.
• Integration tip for mixed stacks: if you're genuinely straddling Laravel and Symfony (e.g., a Laravel app calling a Symfony service), don't try to bridge the bundle into Laravel's Mail facade. Call the Symfony side over HTTP or a queue message, or just use Laravel's native Mail on that side. Forcing a Symfony bundle into Laravel's container is more work than it saves.

Gotchas and Tips

• Adoption risk is the headline gotcha. 2 stars, 0 dependents, and a generic name mean you should assume no community support, no security review, and potentially stale Symfony constraints. Check the last commit date and open issues before committing. Pin the version in composer.json.
• It is not Laravel-compatible. No service provider, no facade, no config/mailer-bundle.php. If your assessment brief is Laravel-flavored, the honest conclusion is: use Laravel's built-in Mail and skip this package entirely.
• Config key and service IDs must be read from source. Guessing wandi_mailer vs wandi_mailer_bundle or a service alias like wandi.mailer wastes an hour. php bin/console debug:container --show-private | grep -i mailer after registering the bundle confirms exactly what got wired.
• Transport/DSN confusion is the most likely runtime failure. If the bundle predates symfony/mailer (i.e., built on Swift Mailer), it won't understand MAILER_DSN and you'll need the legacy mailer_transport/mailer_host style config. This is the first thing to verify in composer.json.
• Extension points are thin. With a package this small, expect limited events or decorators. The safest extension point is wrapping, not subclassing: decorate the bundle's mailer service with your own class (Symfony decorates: in services.yaml) to add logging, retry, or recipient allow-listing for non-prod environments.
• Debugging: php bin/console debug:config wandi_mailer (adjust key) to see resolved config, and run with a Mailpit/symfony/mailer null:// transport to isolate whether failures are the bundle or the network.
• Have an exit plan. Because dependents are zero, assume you may be the maintainer within a year. The adapter pattern above (inject your own interface, delegate to the bundle) is what makes that exit cheap. If the bundle is just a thin wrapper around symfony/mailer, seriously consider using symfony/mailer directly and skipping the abstraction layer entirely.