Active
Project:
Drupal core
Version:
main
Component:
base system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
20 Dec 2018 at 22:47 UTC
Updated:
19 Feb 2024 at 10:58 UTC
Jump to comment: Most recent
Problem/Motivation
Symfony allows you to specify a resource key in your services.yml file. This allows you to search a location and create services automatically.
In Symfony it often looks like
# config/services.yaml
services:
# default configuration for services in *this* file
_defaults:
autowire: true # Automatically injects dependencies in your services.
autoconfigure: true # Automatically registers your services as commands, event subscribers, etc.
public: false # Allows optimizing the container by removing unused services; this also means
# fetching services directly from the container via $container->get() won't work.
# The best practice is to be explicit about your dependencies anyway.
# makes classes in src/ available to be used as services
# this creates a service per class whose id is the fully-qualified class name
App\:
resource: '../src/*'
exclude: '../src/{Entity,Migrations,Tests,Kernel.php}'
# ...
Whilst resource: './src/*' would create way to many services if you organise your project so that all services are in src/services then this could be useful especially when combined with #3021898: Support _defaults key in service.yml files for public, tags and autowire settings.
Proposed resolution
Implement this by copying code from YamlFileLoader once #3021898: Support _defaults key in service.yml files for public, tags and autowire settings has landed.
Remaining tasks
User interface changes
None
API changes
@todo
Data model changes
None
Release notes snippet
@todo
Comments
Comment #2
alexpottCreated a meta
Comment #3
alexpottI don't think this is that useful without autowiring and defaults
[Edit: @Wim Leers is right]
Comment #4
wim leerswithout, I think?
Comment #5
fgmProbably:
Comment #6
alexpott@fgm yep that's why the issue summary says:
Also it's not just making things private - there are other optimisation passes Symfony are doing that we probably should take a look at.
Didn't know what AIUI stands for - according to the Internet it might be "As I Understand it" - so going on that - they would get names based on their class name even without auto-wiring. But still I'm not sure that supporting this is worth it without #3021803: Document and add tests for service autowiring as already commented because it's the automatically getting everything in the container + auto-wiring that saves all the boilerplate.
Comment #7
alexpottNote that adding support for this is not simple because in Symfony land this ability depends on code in symfony/config and we've avoided including that. See #1632930: Add Symfony/Component/Config despite Symfony potentially releasing BC-breaking updates after 2.3. for some discussion. Note we can go our own way here we just need code to do that.
Comment #9
aaronbaumanAdding related issue #2611816: Update to symfony 2.8, in which autowire support was added.
So, this is postponed only on #3021898: Support _defaults key in service.yml files for public, tags and autowire settings
Comment #10
jelle_sRE #7: I'm not very much in favor of reinventing the wheel, when the code that provides us with this functionality already exists in Symfony. Based on my questions, and Lynn's answers in https://github.com/symfony/symfony/issues/32847, maybe we should reconsider using the symfony config component? Lynn made some very good points in that issue.
Comment #17
longwave#3021898: Support _defaults key in service.yml files for public, tags and autowire settings landed.
Comment #19
andypostComment #20
effulgentsia commentedThere's a use-case for this in #3326246: Add symfony/config to core's dependencies for package_manager.
Comment #22
longwaveWe have autowiring and autoconfiguration now; this would be useful so you could say
and then the container would automatically discover all event subscribers in that directory; to add a new one, you just add a new file and rebuild the container. We could even implement this sort of thing by default for modules so they don't necessarily have to write a services.yml at all!
However, there is quite a lot of Symfony code to port over. YamlFileLoader relies on the parent FileLoader class to do a bunch of discovery work here. The two options are:
Symfony's container has diverged quite a lot from ours. I am leaning towards option 2 as it is simply a lot less work, and we would get all Symfony 3/4/5/6's features that we haven't implemented yet for free or almost free.
Comment #23
dpiI've created an alternative proposal to
resourcethat'll help us advance an equivalent more suitable in the Drupal context @ #3422359: Directory based automatic service creation.Perhaps it'll be easier to get something more Drupaly in.