The getService() code says it’s deprecated and will be removed in 3.1. The comment suggests using the dependency injection container.
I’m converting an extra that sends email, but as far as I can tell, it’s not available in the DI system (which is pretty empty at this point). All the email examples in the core code I could find still use getService().
I hate to do the conversion if it’s going to crash when 3.1 comes out.
Is there some way around this?
I doubt getService will be removed in 3.1 given many services have not been migrated. That 3.1 mention may have just been wishful thinking as semver dictates that can’t be done until 4.0.
If a service is in (or can be added to) the container, use that when you can. If it isn’t but still works with getService, use that and don’t overthink it now. 
This needs to be an issue in GitHub if the core is still using the deprecated logic.
This needs to be an issue in GitHub if the core is still using the deprecated logic
Is it feasible for me to check the DI container and add the mail.modPHPMailer service if it’s not there already, then get it?
I don’t know what that would look like, but it would allow me to update several extras that could throw a fair number of deprecation errors in MODX 3.
I’m thinking through this—give me a little bit to consider some options here. It would be better if the container was configured upfront rather than on-demand within an extra, as that is the reason the method was deprecated. If different extras attempted to configure different service implementations, it could turn into a real mess.
@opengeek Good point. I think the list in my bug report is complete, so it should be possible to add those. I think mail, lexicon, and hashing are the only ones that affect my extras.