The Symfony Mailer component was released for the first time in Symfony 4.3, released in May 2019. Since then, we have worked on improving it by adding more third-party providers and adding some missing features that were already available in Swiftmailer, like DKIM support and email signing.
As of Symfony 5.3, all Swiftmailer great features and more are available in Symfony Mailer.
Now comes the time to officially end the maintenance of Swiftmailer in favor of Symfony Mailer. I've set the end of maintenance date to the end of November 2021, at the same time as the Symfony 5.4 LTS and 6.0 release.
Symfony Mailer could actually have been called Swiftmailer version 7 and the work started exactly as the next major version of Swiftmailer.
Let's dive a bit into how I decided to create Symfony Mailer instead of releasing Swiftmailer 7. The current code infrastructure for Swiftmailer was designed for version 4.0, which was roughly released at the same time as symfony 1.2!
For many years, I've tried to work on modernizing the Swiftmailer code base one step at a time by trying to introduce namespaces, move to the Composer autoloader, trying to remove the special (and heavy) "boot sequence", trying to switch to the Symfony dependency injection and event dispatcher components. But all my efforts always finished as dead ends, probably because the task was too important for little benefits as Swiftmailer suffers from many more conceptual issues: it has a weird and complex class inheritance and message instances are not data objects which makes it painful to serialize them. It also lacks some modern features like supporting Twig for composing emails and support for third-party providers. Both features could have been added to the current code base, but it would not have been ideal. Another issue is the way Swiftmailer uses a "spool" mechanism to support asynchronous emails; it barely works and it's not very flexible. I can go on and on, but you get the point.
So, at some point, I decided to start again, but with a very different and radical approach. Instead of trying to modernize the code one step at a time, I've copied the code and started to first work on isolating a Symfony Mime component. Then, I refactored the rest of the code base as much as possible to create Symfony Mailer. The result is Symfony Mailer. Symfony Mailer has quite a lot of code in common with Swiftmailer but none of its idiosyncrasies.
Migrating from Swiftmailer to Symfony Mailer is a relatively easy task as the concepts are the same between the two projects.
It's really a sad state of the ecosystem if everything becomes "symfony" instead of separate components that work great together thanks to interfaces. At some point, one won't even know anymore if a component is the only one you can and must use, or if you can replace it, or even use separately with other code from another vendor, which was clearly the case with swiftmailer's kind of independance. The wider php community is destroyed by aggregating everything into one.
The fact that it's under the Symfony namespace does not change anything in terms of separate components. You can use the Symfony Mailer component independently of everything else like you are doing today with Swiftmailer. The great benefit is that I was the only maintainer of Swiftmailer whereas Symfony Mailer benefit from the support of the whole Symfony core team.
I don't really understand what you mean @fortin81. It's just a package with a name. Nobody if forcing any one thing in the community. You can use this package or not. If you want another package or create something yourself that's still possible. Could be nice if there was a mailer PSR or something. But even symfony mailer can be adjusted to your needs or preffered way of working.
It would be nice to have an upgrade guide. Notable as there's the symfony/swiftmailer-bundle package and configuration.
@fortin81 You raise a valid concern.
AFAIS the dependencies which are a bit too strict would be:
Source:
https://packagist.org/packages/symfony/mailer#v5.3.4
So if you think the package could benefit from replacing/loosening these dependencies (e.g. "psr/event-dispatcher-implementation" instead of "symfony/event-dispatcher") you are welcome to suggest changes and push PRs which implement them. Afterwards you'd have a package with the bare minimum of Symfony dependencies which should be easy to integrate anywhere.
@fortin81 @Mathias Brodala The 2 "-contracts" packages are not really dependencies in that sense. Contract packages contain interfaces, to decouple things even more from the framework (i.e. any PHP package can implement these interfaces to replace bits of the Mailer), like the PSR packages provide.
The EventDispatcher is a critical part of how the Mailer functions. It makes no sense to remove that dependency, as it would mean that the Mailer component has to copy-paste the code from the EventDispatcher component. Also note that the EventDispatcher component doesn't have any dependencies.
In other words: yes, these packages also start with "symfony/", but no they also don't mean your application will be "symfonified". Symfony is a set of reusable components, which means you can use them easily in any PHP application, and we don't have to write the same logic over and over again (like event dispatchers).
I think its a good thing - Mailer is sooo good.
Though, i would properly improve the documentation with a "quick example" on how to send a mail (without using framework)
Just like it does on swiftmailer documentation - usage
Not a single word on how to craft MailerInterface in the mailer documentation.
For those who just needs to send a fast mail out
You can find a simple and more complex standalone example in the README of the Mailer component: https://github.com/symfony/mailer#getting-started
Boum, Fabien strikes again 😉
Hopefully you can fix the bug with DKIM and templated emails
+1 for templated emails with DKIM
During the migration process be aware of this bug https://github.com/symfony/swiftmailer-bundle/pull/313 when you consider putting
symfony/mailerandsymfony/swiftmailer-bundlewith configured memory spool in the same symfony project.Just as a heads-up, based on this discussion we've removed the "symfony/event-dispatcher" requirement in favor of "psr/event-dispatcher" in the 5.4 dev branch: https://github.com/symfony/symfony/pull/42662
Admittedly, I don't follow Symfony development this closely, so maybe I missed some announcement. But declaring on August 20 that Swiftmailer will be EOL at the end of November is a bit short notice, no?
Especially since Symfony Mailer (which I hadn't looked at earlier and which seems to have only one page of documentation) doesn't seem to cover all the functionality Swiftmailer had (e.g. what is the replacement for Swift_Plugins_RedirectingPlugin? Or plugins in general?). Also, there are some issues with handling embedded images that currently make it impossible for me to port my code over (yes, I've opened a ticket for this)