- Issue created by @geek-merlin
- 🇩🇪Germany geek-merlin Freiburg, Germany
This does the trick for me. Tested on a site with hundreds of autoconfigured hook services. Also fixes the related issue.
- 🇦🇺Australia dpi Perth, Australia
I'd like to understand the pain point a little better. Why not use put things in Hooks/ namespace and let it all get registered for you? That way you don't need to put anything in any services file?
Is there a particular reason why that doesnt work for you? Are you using services.yml for some reason?
Manually tagging services and adding to the yml files is something I consider to be a very rare occurrence, not business-as-usual.
- 🇩🇪Germany geek-merlin Freiburg, Germany
In a small codebase it is practical to have hooks in a separate autoregistered dir.
When having custom modules with thousands of highly coupled sub-components, you'd get mad with that.
In our organisations we have a policy to bundle stuff together in dedicated dirs, including hooks.
With big codebases, we're doing php-driven autoregistration without services.yml (as core decoupled from sf and is still bikeshedding about that).
Quite some dev dudes i know with big code bases do it like this. - 🇦🇺Australia dpi Perth, Australia
With big codebases, we're doing php-driven autoregistration without services.yml (as core decoupled from sf and is still bikeshedding about that).
Quite some dev dudes i know with big code bases do it like this.Thanks @geek-merlin, this makes sense, and allows me to approve this issue. I also prefer everything in `src` as a service, relying on private/service removal if unused, per Symfony.
Perhaps you'd be interested in taking a look at a core ticket I created a year ago: ✨ Directory based automatic service creation Needs work to help de-bikeshedding core ;)
Something needs to be done about the HuxCompilerPass2 name, and I'll do a deeper review. This will happen when I can get to it next, but isnt a high priority. Tests, docs, updates also
