Problem/Motivation

Autoconfigure (https://symfony.com/doc/current/service_container.html#services-autoconf...) allows to skip a lot of boilerplate with compiler passes etc. like automatically adding a service tag if a service implements a particular interface.

However, it only works if the individual services.yml specifies autoconfigure: true, so for existing compiler passes, can cause bc issues for modules that don't do this.

Can we somehow deprecate not having autoconfigure: true in services.yml? Or change Symfony's default to true while allowing people to explicitly disable it? Not sure, but opening this issue to discuss.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Issue fork drupal-3449569

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

catch created an issue. See original summary.

kim.pepper’s picture

This could be a novice issue if we are just adding autoconfigure: true to all the services.yml's

ghost of drupal past’s picture

I read the page you linked and solely based on how AsEventListener behaves -- which I have studied for the OOP hook patch -- I think you will be very disappointed at what autoconfigure: true actually provides with the components Drupal core currently uses: it is registered here aka in the full symfony/symfony package. twig.extension is added in Symfony\Bundle\TwigBundle\DependencyInjection\TwigExtension which does ship with Drupal core but as far as I am aware, Drupal doesn't use Symfony bundles at all.

This is not to say it is completely useless -- but it does require some work, a bit of copy/paste at least to make it really useful. It's not a lot by any means, AsEventListener is like six lines of code, the twig register code is one line per twig tag , three lines in total etc

catch’s picture

kim.pepper’s picture

Status: Active » Needs review

Given we are held up with concerns in #3452304: Turn autowire & autoconfigure ON/OFF globally should we go ahead and do it the manual way here first?

I was curious so I added autoconfigure: true and autowire: true to every services.yml file to see what happens.

catch’s picture

Yeah I think we should manually configure autoconfigure everywhere (what a sentence) in core whatever happens. The test failures in the MR show we might run into issues doing #3452304: Turn autowire & autoconfigure ON/OFF globally for contrib too, but maybe it'll help us figure out what to do there.

kim.pepper’s picture

I also added autowire: true everywhere too, which I think we should remove and just do autoconfigure: true first.

andypost’s picture

kim.pepper’s picture

I've toned this down to only add autoconfigure: true to non-test modules. I had to exclude the mysql.services.yml too for reasons I haven't looked into.

longwave made their first commit to this issue’s fork.

longwave’s picture

Status: Needs review » Reviewed & tested by the community

I agree with doing this as it sets a good precedent for contrib and custom code to copy, I also enabled it for announcements_feed which was missed from the MR.

The reason that mysql fails is that mysql.views.cast_sql implements a Views interface, but not all tests enable Views, so the interface cannot be loaded during container rebuild in some tests. I don't think this is worth trying to work around - database drivers are probably a special case here.

However, this probably means that we can't globally enable it for cases like this where services have dependencies that might not necessarily always be available.

  • alexpott committed bbd5898b on 10.4.x
    Issue #3449569 by kim.pepper, longwave, catch: Use autoconfigure more in...

  • alexpott committed 0bfb4c79 on 11.0.x
    Issue #3449569 by kim.pepper, longwave, catch: Use autoconfigure more in...

  • alexpott committed 2588e097 on 11.x
    Issue #3449569 by kim.pepper, longwave, catch: Use autoconfigure more in...
alexpott’s picture

Version: 11.x-dev » 10.4.x-dev
Status: Reviewed & tested by the community » Fixed

Committed and pushed 2588e097a9 to 11.x and 0bfb4c7978 to 11.0.x and bbd5898ba6 to 10.4.x. Thanks!

Backported to 10.4.x as this is a task and not necessary to be a part of 10.3.x

Status: Fixed » Closed (fixed)

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