Add a Autowire trait for plugins

Drive by code drop. Not working on this for now.

Nice. I was looking for exactly this today!

I have tested the code together with Drupal 10.3 and can confirm it works.

Since I wanted to have the benefit of this right away, I took the liberty and made it a small module: https://www.drupal.org/project/autowire_plugin_trait →

Also see ✨ Add a trait for autowiring properties in tests Needs work .

There I’m suggesting to add symfony/expression-language as a dependency.

That would nicely allow using expressions and enable autowiring of constructs like

#[AutowireProperty(expression: "service('entity_type.manager').getStorage('node')")]

Can we just extend the existing AutowireTrait to work here?

  public static function create(ContainerInterface $container) {
    $args = [];

becomes

  public static function create(ContainerInterface $container, ...$args) {

ie. additional arguments passed to create() become the initial set of arguments?

No, #8 doesn't work because ContainerFactoryPluginInterface::create() doesn't match.

Added AutowirePluginTrait to PluginBase to enable autowiring by default (simply omit the create() method) and autowired some Views plugins to test that it all works.

Does this even need to be a trait? Should it just be included directly in PluginBase?

Not sure we need explicit tests, given we are exercising it in Views tests now, so removing the tag.

Adding the trait to \Drupal\Core\Plugin\PluginBase (not Component) seems to work, I autowired the BlockContentBlock plugin to prove it.

Shouldn't there be a test coverage for the new exception being thrown?

 throw new AutowiringFailedException($service, sprintf('Cannot autowire service "%s": argument "$%s" of method "%s::_construct()", you should configure its value explicitly.', $service, $parameter->getName(), static::class));

Added coverage for success and failure of autowiring a block plugin.

In fact let's do the refactor in #14 now to avoid copy-pasting the code here.

Regarding the phpstan baseline, it turns out that phpstan will accept @return annotations, and we already have that in ContainerFactoryPluginInterface, but PluginBase does not yet implement that interface. Have pushed a commit to implement that interface and update the baseline.

Unfortunately implementing ContainerFactoryPluginInterface in PluginBase breaks a bunch of tests, I don't think Migrate plugins can cope with this as they have a slightly different constructor.

Rebased.

This one needs a rebase.

Only change is core/.phpstan-baseline.php.

I pushed in a new branch, is it preferred to do a force push on the PR, or merge into the branch and avoid overriding it?

There was already an existing branch pointing to the right branch that feedback has been made on. That should be used.

Phpstan should be regenerated

dydave → changed the visibility of the branch 3452852-autowire-trait-plugins-rebase to hidden.

As per #25:

Conflicts were resolved in the initial merge request MR!8306 when the branch was rebased on 11.x.

Switching back to Needs review.

Thanks in advance!

smustgrave → closed merge request !10867

Pipeline appears to have conflicts. Not sure if the baseline file was manually fixed but it should just be re-generated

As Mentioned in #30 , i have fixed the pipeline failure by generating the baseline. pipeline is passing , so moving this again NR.