Use autoconfigure more in core

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

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.

Given we are held up with concerns in ✨ Turn autowire & autoconfigure ON/OFF globally Needs review 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.

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 ✨ Turn autowire & autoconfigure ON/OFF globally Needs review for contrib too, but maybe it'll help us figure out what to do there.

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

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.

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.

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

kim.pepper → closed merge request !8287