Use tagged iterator in plugin.cache_clearer instead of a lazy service

Postponed until we land 📌 Use a tagged service iterator for uninstall validators instead of individual lazy proxies Needs review or 📌 Add support for tagged_iterator to YamlFileLoader Active so we can use tagged iterators without having to add support code.

Any recommended way for testing this one?

It's a kinda low level refactoring, any automated test coverage that uses the plugin.cache_clearer service directly or indirectly should be enough to prove I haven't broken anything.

Ran the test-only feature https://git.drupalcode.org/issue/drupal-3432827/-/jobs/1378533 which I'll admit I'm leaning on.

Looking at the refactor though don't see anything that stands out that could be a problem. And tests are still passing.

This looks good. There are constructor and interface changes here, but I really wonder why we have an interface for this at all.

Tried to think what a deprecation looks like, I think we need a 10.3.x MR that adds @deprecated to the interface method we're removing. I'm not sure we should do anything else though because this is so low level and unlikely to be interacted with. Added a CR.

The problem is that by leaving the method on the interface, even if deprecated, is that anyone else implementing has to also leave the implementation in place. Instead I have still removed the method from the interface, but kept it on the concrete class, and added BC so it still works but issues a deprecation if you call the old method.

This is also too late for 10.3 now, so I have deprecated in 11.1 for removal in 12.0.

Failure seems unrelated to this change, HEAD may be broken as I'm seeing the same failure across multiple MRs

Deprecation update seems good though.

@longwave why did you remove autoconfiguration?

@alexpott that only works if you specify autoconfigure: true in each services.yml that declares a plugin manager, so it's not backward compatible (similar to what we found in 🐛 Adding media library openers use autoconfigure and tags in 10.3.x has BC consequences Active )

Question answered, back to RTBC.

OK yeah I tried to use autoconfigure in another MR recently and ran into the same issue that every services.yml needs to enable it. We should open an issue to do that in core and try to figure out a way to encourage contrib to do it (or could we switch things so it's enabled by default in a minor?).

Also talked to @longwave about whether we should try to backport this to 10.4.x, but since it shouldn't affect contrib at all, it doesn't really help with 10.4.x/11.1.x compatibility. So... let's leave it in 11.1.x.

Committed/pushed to 11.x, thanks!

Opened 📌 Use autoconfigure more in core Active .

Adding tag for follow up in #19

The change record is mostly a diff. The change record should explain the change, what sites are affected and the action that needs to be taken.

Opened 📌 Enable autoconfigure for services.yml Active

Not sure I can update the CR

Fixed the change record. I hardly can imagine that anybody is overriding this service or calling into addCachedDiscovery() from some weird place. What do I know, though...

The followup created in in #22 was closed as a duplicate. The follow up already existed, it is 📌 Use autoconfigure more in core Active

@znerol, thank you. That is much better.

The change record is published.

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