Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[DependencyInjection] Accessing processed extension configs#48408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
9a47590 to6be13c9CompareOskarStark commentedNov 30, 2022
Regarding the PR headline - [DependencyInjection] Accessing to processed extension configs+ [DependencyInjection] Accessing processed extension configs |
stof commentedNov 30, 2022
Big -1 for this, as it means that the structure of the processed config becomes a public API covered by BC, making it impossible to refactor the config anymore, while the Configuration class is currently the perfect tool to provide a BC layer for the config structure (converting old structure into the new structure expected by the extension). |
stof commentedNov 30, 2022 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Another -1 is that you expose that parameter with a partial value to DI extensions, making them very sensible to the bundle loading order. Currently, each DI extension receives a dedicated ContainerBuilder that has none of the services defined by other bundles precisely to reduce the risk of implementing something in the DI extension that should be done in a compiler pass instead to allow collecting services from any other bundle. Note that the early preview versions of Symfony 2.0 did not have this isolation layer, and it caused lots of issues for early adopters when doing stuff in DI extensions instead of implementing a compiler pass. So we have implementation experience proving that it is a bad architecture (making it easier to write broken code than correct code). |
yceruto commentedDec 4, 2022
Fair enough, thanks for the feedback. |
This proposal adds a new container parameter
.extension.processed_configsthat holds all processed extension configs from all registered extensions in order to improve the DX during the DI compilation phase (load extension, compiler pass).Before
Currently, it's not possible to access processed configs, so this new parameter will avoid unsafely and hacking workarounds just to query a config value that belongs to another (already processed) extension and derives some DI definitions from it.
Some workarounds involve:
processConfiguration()method from another extension is forbidden as it's protected and final, meaning you'll have to process twice this config outside the extension owner.After
With this proposal, you'll access these configs through the
.extension.processed_configsparameter. It's an array of extensions configs, where the array key matches the extension alias:Note that in
loadorloadExtensionyou have access only to already loaded extensions depending on the extension/bundle definition order. If you need access to other extension configs that are not loaded yet then move your logic to a compiler pass or change the bundle/extension order in thebundle.phpfile of your project.Also available in any compiler pass with the capability to resolve env placeholders:
After merging#47680 this
.extension.processed_configsparameter is considered a "build parameter" finally, so it will be used during compiler time only and will be removed at the end of the process.