Mail Laravel Package

Getting Started

Read the room first: this is not a Laravel package. youshido/mail is a Symfony bundle (registered via AppKernel/bundles.php), so there is no service provider, no facade, no config/mail.php merge, and nothing that auto-discovers in Laravel. With a last release in April 2016, 1 star, and zero dependents, treat "getting started" as an archaeology exercise, not an install.

Minimal steps:

1. composer require youshido/mail in a throwaway Symfony 2.8/3.x sandbox — not in your production app. Check composer.json first: PHP constraint, autoload standard (PSR-0 vs PSR-4), and whether it pulls swiftmailer/swiftmailer (EOL since Nov 2021).
2. Look at the source before anything else. There is no maintained README, so the documentation is:
   • MailBundle.php — bundle class, compiler passes.
   • DependencyInjection/*Extension.php — the load() method is your config schema; every ->rootNode() child is a key you must supply or that has a default.
   • Resources/config/services.* — service IDs and constructor args. This tells you what to inject and what it wraps.
   • The mailer class itself — the only thing you may actually want.
3. Register the bundle and supply the config keys you found in step 2. Expect at least transport-ish settings and possibly a template path.
4. First use case: send one templated transactional email (welcome, receipt) by injecting the bundle's mailer service into a thin controller/service, passing a template name + data array, and asserting the message on a null/spool transport.

If you are in Laravel full-time, the realistic "first use case" is reading the mailer class to see how it renders a template into a message, then writing the 40-line Mailable + Blade view that does the same thing natively.

Implementation Patterns

Anti-corruption wrapper (the main pattern). Never let the bundle's service leak into your controllers. Define your own App\Mail\Notifier interface (send(string $template, array $data, Recipient $to)), implement it once with the bundle's mailer, and inject the interface everywhere. Given the abandonment risk, this makes swapping to Symfony Mailer or Laravel's Mail a one-file change.

Inject, don't instantiate. The whole value of a bundle is DI. Constructor-inject the mailer service into your own services; keep controllers to a single call. If the service is not in the container, bin/console debug:container <id> immediately tells you the extension didn't load or a required config node is missing.

Template-per-message. Keep bodies in templates and pass a plain data array — no HTML string-building in PHP. Where the bundle expects templates (its own Resources/views vs app/Resources/views) is a config key; pin it explicitly rather than relying on the default.

Transport separation. If the bundle delegates to Symfony's Swift Mailer config (mailer_transport, mailer_host, …), keep environment-specific transport in parameters, and in tests use a spool/null transport so nothing leaves the machine. If the bundle does not expose the composed message, your wrapper should, or you cannot assert on subject/recipients/body.

Laravel translation pattern. Don't attempt to register a Symfony bundle in Laravel. Port the concept:

• Template + data → Mailable with a Blade/Markdown view.
• The bundle's mailer call → Mail::to($user)->send(new WelcomeMail($user)).
• Queueing, which the 2016 bundle almost certainly lacks, comes free with ShouldQueue.

Symfony 5+/6+ translation pattern. Replace the bundle service with Symfony\Component\Mailer\MailerInterface + Email/TemplatedEmail. Keep your Notifier wrapper so the call sites survive the swap.

Gotchas and Tips

• Swift Mailer is dead. Any code path that hands a Swift_Message to a transport will not run on Symfony 6+ (Swift Mailer was removed). This alone disqualifies it from a greenfield build.
• Deprecated APIs are likely. 2016-era bundles commonly use the Templating component (templating.engine.*), $this->container in controllers/commands, or getContainer(). Templating was removed in Symfony 5.0, so those code paths fail before your first email is sent.
• Config node with no default = bundle won't boot. If the extension defines a required scalar and you omit it, you get a InvalidConfigurationException at container compile time, not at send time. Read load() to know exactly which keys are mandatory.
• Autoload mismatches. Old packages often ship PSR-0 or a vendor namespace that doesn't match the path. If composer require succeeds but classes aren't found, check composer.json's autoload section and run composer dump-autoload -o.
• No security response. One star and zero dependents means no one is watching advisories. If you must ship it, fork it, pin it to an exact version, and own the patches. Prefer replace/path-repo over a floating constraint.
• Debugging checklist: bin/console debug:container --tag=... for registration → debug:config <alias> for the resolved config tree → spool transport to inspect the raw MIME → only then suspect the mailer class.
• Extension point is the wrapper, not the bundle. Don't patch vendor code; subclass or decorate the bundle's service and register yours under the same interface. Keep the interface generic (send(template, data, recipient)) so the bundle is an implementation detail.
• Bottom line for a Laravel developer: the adoption cost exceeds the value. Use Mail + Mailables (or Symfony Mailer/Notifier on Symfony); borrow only the templated-mailer idea from this repo's source.