MR Updated against the latest state of 1.0.x branch.
Yep thats all that was needed, LGTM then
Once this lands, or we decide on changes happy to update as needed - same goes for the connected issue :) - and it does work for me (I'm also using this patch to inject alternative transports)
I completely agree that once this comes into core that the whole concept of maybe even the majority of the wiring this module is doing becomes obseleted, in the mean time though I guess what I'm thinking about is effectively keeping things as close-to a per-documentation implementation of a symfony transport factory registration.
We're not taking it over, we're just another factory that can listen out for other registrations of the transport factory - which is the sole reason I was going with the `mailer.transport_factory` tag - it keeps us aligned to what Symfony mailer is telling you to do in the documentation vs this being firewalled off.
Transport::getDefaultFactories() is another shortcut which will fall on our feet sooner or later. I humbly recommend to avoid that as well.
I totally appreciate the point, but in the same thought, it was not about trying to replicate the fully fledged implementation, just a means to allow a base line with some extensibility to it. Key thing is that its not on the deprecation path just yet, and given Symfony 7.1 still maintains it (and we're using ^6.4 in 10.x, and given Symfony's current release still contains this API, 7.1 (which is released in May) still has it, so deprecation would (if it is indeed deprecated) be 8.0 which by their own definition is due November 2025. So wondering what the worry is around falling back on this?
I figure given they are defaults that we can rely on them to be available without having to register them - I have updated the MR so that we merge them to the end of the array when retrieving the transport factories though as otherwise it inadvertently gives them priority.
The tag name is deliberate though, as that way we're reacting to the service tag thats in the symfony mailer documentation. In theory it means if someone is doing work using this module, that we're not incompatible with how symfony_mailer or potentially even the linked conversation for core.
Fortunately the compiler pass on the container should deal with many different service collectors using the same tag; Symfony is able to register each service using the mailer.transport_factory service tag against each collector (collecting this tag ofc). So we wouldn't be in competition AFAIK.
I've just raised what I'd class as MVP at least to be able to leverage the mailer.transport_factory tag by allowing the TransportsFactory to hold factories (seeded with the default)
dan.munn → made their first commit to this issue’s fork.
dan.munn → created an issue.