Enable more service autowiring by adding interface aliases to core modules

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Looks good to me. RTBC.

Going OT a bit: how about https://symfony.com/doc/current/service_container/autowiring.html#dealin...? This would help autowiring for cache bins and for loggers like e.g.

  cache.default:
    class: Drupal\Core\Cache\CacheBackendInterface
    tags:
      - { name: cache.bin }
    factory: ['@cache_factory', 'get']
    arguments: [default]
  Drupal\Core\Cache\CacheBackendInterface $cacheDefault: '@cache.default'

Thanks. Not sure yet what approach would work for cache bins (feel free to open a followup!), but for loggers I think binding a default per module could work, see #3295542-3: Use logger channel services consistently, instead of the factory object → .

Needs rebasing

Rebased, back to RTBC.

1. Looks like there is 1 unresolved comment (that got addressed but was never marked as resolved): https://git.drupalcode.org/project/drupal/-/merge_requests/3075#note_137045)

2. The merge request is currently blocked and needs a rebase.

Thank you!

Rebased and resolved the comment, back to RTBC.

A lot of these services are ones I would never expect to be used outside the module. This issue doesn't really make that any more or less the case but wondering if we really want to do this for every service in core.

@catch the followup to this is 📌 Use autowiring for core modules and services Needs work where we can start using autowiring for real across core, and don't have to specify exact arguments any more for a large number of service definitions.

Oh I didn't think about within the module itself... makes sense then.

Committed/pushed to 11.x (10.2.x), thanks!

Filed 📌 [policy] Service autowiring - decide approach for multiple service implementations based on the same class and different arguments Needs work as a possible followup.

Automatically closed - issue fixed for 2 weeks with no activity.

It needs follow-up according to #3354584-14: Deprecate TrustedCallbackInterface in favour of TrustedCallback attribute →

some classes that used to implement interface now brings false positive

This needs a CR to say that most core services need an interface alias.

The test assertion and test docs also needs more detail, otherwise adding a new service to core just gets you this confusing test failure and you're left doing git archeology to find this issue :(

Failed asserting that two arrays are identical.
--- Expected
+++ Actual
@@ @@
     'Drupal\Core\Asset\AssetQueryStringInterface' => 'asset.query_string'
     'Drupal\Core\Config\ConfigManagerInterface' => 'config.manager'
     'Drupal\Core\Config\ConfigFactoryInterface' => 'config.factory'
-    'Drupal\Core\Config\ConfigImporterFactory' => 'config.importer.factory'
     'Drupal\Core\Config\ConfigInstallerInterface' => 'config.installer'
     'Drupal\Core\Config\StorageCacheInterface' => 'config.storage'
     'Drupal\Core\Config\ImportStorageTransformer' => 'config.import_transformer'

We could use 🐛 Improve AutowireTest to ignore TrustedCallbackInterface Needs review for that