[FrameworkBundle] Allow using their name without added suffix when using #[Target] for custom services
#60874
Conversation
Valmonzo
commented
Jun 23, 2025
| Q | A |
|---|---|
| Branch? | 7.4 |
| Bug fix? | no |
| New feature? | yes |
| Deprecations? | no |
| Issues | Fix #60349 |
| License | MIT |
LockFactory servicesLockFactory services
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php
Outdated
Show resolved
Hide resolved
LockFactory servicesLockFactory services
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
There was a problem hiding this comment.
Workflow works because it has two lines:
$container->registerAliasForArgument($workflowId, WorkflowInterface::class, $name.'.'.$type);
$container->registerAliasForArgument($workflowId, WorkflowInterface::class, $name);HttpClient/Cache work because they don't add any conventions: scoped clients' / cache pool names are their service names.
And there are other subsystems that create their own conventions:
$container->registerAliasForArgument($serializerId, SerializerInterface::class, $serializerName.'.serializer');
$container->registerAliasForArgument($serializerId, NormalizerInterface::class, $serializerName.'.normalizer');
$container->registerAliasForArgument($serializerId, DenormalizerInterface::class, $serializerName.'.denormalizer');
$container->registerAliasForArgument('assets._package_'.$name, PackageInterface::class, $name.'.package');
$container->registerAliasForArgument('lock.'.$resourceName.'.factory', LockFactory::class, $resourceName.'.lock.factory');
$container->registerAliasForArgument('semaphore.'.$resourceName.'.factory', SemaphoreFactory::class, $resourceName.'.semaphore.factory');
$container->registerAliasForArgument($limiterId, RateLimiterFactoryInterface::class, $name.'.limiter');Looks like they would all benefit from something similar, isn't it?
To improve the situation, we could add an argument, $target to registerAliasForArgument (using a proper BC layer). The implementation would just create this second alias we're considering to add here.
And we would also patch debug:autowiring so that it groups those two lines in one (see "target" entry in the output).
WDYT?
Is this something you might want to work on @Valmonzo?
|
@nicolas-grekas most cases are adding a suffix mostly because they were implemented at a time where named autowiring was based on argument names, where we would expect the argument name (and so often the property name) to end with When using the |
|
So let's start with adding all those aliases and call |
|
@nicolas-grekas given the maintenance cost of the double aliases is low, maybe we should make it easier to support multiple versions of Symfony by delaying the deprecation (you cannot use |
|
I like the fact that one can choose not to use the attribute as it’s less boilerplate for aliases that are used a lot. |
|
Same preference as @chalasr , but whatever you choose, I'll be happy to work on it ! |
|
Fine, then let's also add this line for the other components? See my list above. |
LockFactory services79d2994 to
aa54036
Compare
…ing #[Target] for custom services
aa54036 to
8df6691
Compare
|
Thank you @Valmonzo. |
|
With this PR, the It'd be nice to have display this instead: If anyone reading is up to giving it a try (the logic should be in DebugAutowiringCommand) |
#[Target] for custom services
| @@ -4,6 +4,7 @@ CHANGELOG | |||
| 7.4 | |||
| --- | |||
|
|
|||
| * Allow using their name without added suffix when using `#[Target]` for custom services | |||
There was a problem hiding this comment.
Am I alone in having a problem properly understanding this line? (May-be its the "their" being used before its clear what it is referencing?)
There was a problem hiding this comment.
Imagine you have some services like a LockFactory named foo, before the target worked like #[Target('foo.lock.factory)] LockFactory $lockFactory, now you can use #[Target('foo')] LockFactory $lockFactory
There was a problem hiding this comment.
But from the code diff, this only applies to the concrete services, for which you added suffix-less aliases? Is it really tightly coupled to #[Target] in general, or just for specific services and wouldn't these aliases also work in services.yaml, for example?
It's a silly question, but since we know that |