Deprecate configuring tag names and service ids in compiler passes

[nicolas-grekas]

Q	A
Branch?	5.x
Bug fix?	no
New feature?	no
Deprecations?	yes
Tickets	-
License	MIT
Doc PR	-

This PR is aimed at reducing the code complexity by hardcoding the name of tags and service ids that compiler passes have to deal with.

I think making these names configurable only adds boilerplate and maintenance overhead for no benefit:

• for the practice: the need to use a pass with a renamed tag/id should be extremely rare (do yo know any?)
• for the theory: a decorating pass could still rename before/after the processing, so this use case is still supported.

Side note: I skipped updating changelog+upgrade files. This would be just noise to me (nobody uses this possibility anyway ;) )

[derrabus]

When resolving this deprecation, would you rather…

• … inline all configurable strings?
• … store them in private constants?
• … keep the private properties to keep merges easy?

[nicolas-grekas]

… inline all configurable strings

[veewee]

Looks like we are using it for custom event listener tags in grumphp configuration @nicolas-grekas 👯
Would have been nice to add these kind of things to the changelog nevertheless. Thanks!

[pamil]

It feels like it still can be configured with $eventAliases, what do you think about mentioning $eventAliasesParameter in the deprecation message?

[donquixote]

For the record:
We do use a custom tag name 'event_subscriber' in Drupal.
Currently we also use a custom compiler pass and a custom event dispatcher, but we are considering to move back to the symfony event dispatcher. https://www.drupal.org/project/drupal/issues/2909185
But we need to support the custom tag name for BC.
The reason for the custom tag name was made in the past, https://www.drupal.org/project/drupal/issues/1824400. It can be argued whether this was a good or bad decision.

While most of the events that will get dispatched by our 'dispatcher' service will be kernel events, we'll also be using the same tag for other non-kernel-related events.

I think the tag name 'kernel.event_dispatcher' is not meant to imply that all the events are "kernel events", so this justification seems questionable in hindsight.

for the practice: the need to use a pass with a renamed tag/id should be extremely rare (do yo know any?)

I think these customization options are typically not needed for projects that are built with symfony directly, but they can be useful for other frameworks or systems that use symfony classes and components selectively, instead of using symfony as a complete system.

A good reason for custom tag names and service ids could be to avoid conflicts with other tag names and service ids from non-symfony components, or to have multiple instances of e.g. the event dispatcher - for whichever reason.

for the theory: a decorating pass could still rename before/after the processing, so this use case is still supported.

Or add another pass to rename the tag on each service that uses it - if we don't care if the old tag is restored afterwards.

Still this is less clean than the parameter - but ok.

To be clear: I am not necessarily requesting to revert this, I just want to give feedback on the "nobody uses this".