The end of Swiftmailer
August 19, 2021 • Published by Fabien Potencier
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.
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
AFAIS the dependencies which are a bit too strict would be:
- symfony/event-dispatcher
- symfony/deprecation-contracts
- symfony/service-contracts
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.
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).
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
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)