Weave Code
Symfony Mailer Command Bundle Laravel Package
inspiredminds/symfony-mailer-command-bundle
A Symfony bundle that adds console commands for testing and debugging Symfony Mailer setups. Send test emails straight from the CLI to verify transports, DSNs, and delivery without writing throwaway code—handy for local development and post-deployment checks.
Symfony Mailer Command Bundle adds convenient console commands for sending email through Symfony Mailer, making it easy to verify your mailer configuration from the terminal. Useful for local development, staging checks, or CI pipelines where you need to confirm that transport, DSN, and sender settings work end to end.
- Send a test message with a single console command
- Configure recipients, subject, and body via command options
- Reuses your existing Symfony Mailer transport and DSN configuration
- Ideal for debugging mailer setups and smoke-testing deployments
Frequently asked questions about Symfony Mailer Command Bundle
- What does inspiredminds/symfony-mailer-command-bundle do?
- Despite the Composer name, this is a Symfony bundle, not a Laravel package. It registers a mailer:send console command through Symfony's DI container so you can compose and dispatch an email from the CLI using Symfony Mailer transports. Typical uses are smoke-testing an SMTP or DSN configuration, debugging delivery, and running mail tasks from cron or deployment scripts.
- Is inspiredminds/symfony-mailer-command-bundle compatible with Laravel?
- No, not as a dependency. Laravel 9 and newer use Symfony Mailer as the transport layer, so the underlying transport classes already exist in your vendor directory, but Laravel never loads Symfony bundles, their extensions, or their config trees. Treat the bundle as a reference implementation and rebuild the command as an Artisan command against Laravel's MailManager.
- How do I install inspiredminds/symfony-mailer-command-bundle?
- In a Symfony application, install it with composer require inspiredminds/symfony-mailer-command-bundle and enable the bundle in config/bundles.php; Symfony Flex registers it automatically. It is not installable as a Laravel package because there is no Laravel service provider or Artisan integration. If you only want the behavior in Laravel, port the command rather than adding the dependency.
- Which PHP and Symfony versions does the bundle support?
- The bundle targets PHP 8.1 or newer and Symfony 6 or 7, which aligns with the platform requirements of Laravel 10 and 11. Check composer.json in the repository for the exact constraints before planning anything. The PHP and Symfony compatibility is fine; the Symfony packaging is what does not fit Laravel.
- What license does this package use, and can I use it commercially?
- The package is GPL-3.0, a copyleft license that is a hard blocker for distributed or commercial Laravel products without legal review. Even vendoring or forking the code internally can raise contamination concerns. Get a legal opinion before reading the implementation if clean-room reimplementation matters to your organization.
- How do I use mailer:send to test an SMTP transport or DSN?
- The mailer:send command sends a message through a configured Symfony Mailer transport from the console, which makes it handy for verifying DSN and SMTP settings outside your application flow. Confirm the exact arguments in the README, since the command surface is small and may accept a mailer name, a DSN override, and message content. Exit codes make it usable in scripts, so a failed transport should return nonzero.
- What is the Laravel alternative to this Symfony mailer command?
- Laravel already gives you Mail::mailer('name')->raw($mime, $callback) and the Mail facade for most of what this command does. For a DSN override, instantiate the Symfony transport directly and call send() on the message, or add a small Artisan command that wraps MailManager. A functionally equivalent command is roughly a one-to-two-day internal build and avoids the GPL-3.0 issue entirely.
- Does mailer:send support queues, retries, or transport failover?
- The bundle's command appears to be a synchronous single-send path with no queue, retry, or failover integration. Laravel supports queues, retries, and failover or round-robin transports natively, so building on Laravel's mailer gives you more operational features than the original. Do not assume the Symfony command mirrors that behavior when porting it.
- How do I test an Artisan mail:send command if I build my own version?
- Use Mail::fake() to assert the mail was sent and assert the exit code with $this->artisan('mail:send')->assertExitCode(0). For raw transport paths, inject a fake Symfony transport that captures the sent message and assert on recipients and subject. Test the failure path too, since a mail command that exits zero on transport errors is worse than useless in cron.
- Is this package actively maintained, and should I depend on it in production?
- The project has a single maintainer, two stars, and no dependents, so there is effectively no external validation or downstream regression signal. If you depend on it directly, you own all fixes and upgrades. Replicating the small command internally is a lower-risk long-term position and is probably the right call for a Laravel codebase.
Weaver
How can I help you explore Laravel packages today?