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
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:
- 3449569-use-autoconfigure-more
changes, plain diff MR !8287
Comments
Comment #2
kim.pepperThis could be a novice issue if we are just adding
autoconfigure: trueto all theservices.yml'sComment #3
ghost of drupal pastI 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
Comment #4
catchComment #6
kim.pepperGiven 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: trueandautowire: trueto every services.yml file to see what happens.Comment #7
catchYeah 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.
Comment #8
kim.pepperI also added
autowire: trueeverywhere too, which I think we should remove and just doautoconfigure: truefirst.Comment #9
andypostComment #10
kim.pepperI've toned this down to only add
autoconfigure: trueto non-test modules. I had to exclude themysql.services.ymltoo for reasons I haven't looked into.Comment #12
longwaveI 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_sqlimplements 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.
Comment #16
alexpottCommitted 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