`PluginManagerSetsCacheBackendRule` is currently too strict.

[Boegie]

Feature request

Torn between a bug report or a feature request, but the latter sounds more friendly...

After the excellent work #592 landed in 1.1.37, we looked at dropping the ignore for the Missing cache backend declaration for performance. in Drupal core in https://www.drupal.org/project/drupal/issues/3320569.

As it turns out, for that the current rule is a tad too strict.

In https://www.drupal.org/project/drupal/issues/3377000#comment-15167041 I tried to boil down the requirements:

We want setCacheBackend() in every plugin class __construct(), unless:

• it's the base class, where we define the base class as being the class that has the implementation of setCacheBackend().
• it's a test class.
• it has a parent that already has a setCacheBackend() in it's __construct().

[mglaman]

Yeah, it is a bug if it's not detecting from a parent class.

[Boegie]

Working on a PR as we speak/type/whatever.

[dpi]

Another false positive issue with this rule is you can add a calls entry to services instead of a code entry in the constructor. Without the method call in constructor "Missing cache backend declaration for performance.", despite the container doing the work for us.

services:
  plugin.manager.mypluginmanager:
    calls:
      - [setCacheBackend, ['@cache.discovery', 'mypluginmanagercachekey']]

I like this method since its once less service you need to define manually as a service argument, otherwise you'd need to manually autowire cache services with something like:

services:
  plugin.manager.mypluginmanager:
    arguments:
      $cache: '@cache.discovery'