Problem/Motivation
As of recently, core services that satisfy certain criteria (I'm not sure which!!) need to have a service alias which is their class or interface, to allow autowiring.
E.g.
config.factory:
class: Drupal\Core\Config\ConfigFactory
tags:
- { name: service_collector, tag: 'config.factory.override', call: addOverride }
arguments: ['@config.storage', '@event_dispatcher', '@config.typed']
Drupal\Core\Config\ConfigFactoryInterface: '@config.factory'
SNIP
config.importer.factory:
class: Drupal\Core\Config\ConfigImporterFactory
arguments: ['@event_dispatcher', '@config.manager', '@lock.persistent', '@config.typed', '@module_handler', '@module_installer', '@theme_handler', '@string_translation', '@extension.list.module', '@extension.list.theme']
Drupal\Core\Config\ConfigImporterFactory: '@config.importer.factory'
However, this is extra boilerplate. For services that don't have an interface, it's even just repeating the relationship but the other way round!
This is information that can be deduced automatically in most cases:
1. Determine whether the service should have an autowiring alias
2. How many interfaces does the service implement?
- 1: Use that as the alias
- 0: Use the class as the alias
- 2+: Is not autowired (AFAIK?)
This could be done in a new compiler pass.
It's been pointed out that this reduces discoverability, but autowiring aliases needs better documentation anyway -- https://api.drupal.org/api/drupal/core%21core.api.php/group/container/10 doesn't say which services are autowired and
https://www.drupal.org/node/3323122 →
I *think* says the rules I've used to the algorithm above but I'm not entirely sure.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
