Change Details

As part of T187154#6034369 I noticed the following on enwiki in production: ```lang=json "wgConfigRegistry": { "vector": "GlobalVarConfig::newInstance", "cite": "GlobalVarConfig::newInstance", "categorytree": "GlobalVarConfig::newInstance", "timedmediahandler": "GlobalVarConfig::newInstance", "CirrusSearch": "CirrusSearch\\SearchConfig::newFromGlobals", "globalcssjs": "GlobalVarConfig::newInstance", "globaluserpage": "GlobalVarConfig::newInstance", "ApiFeatureUsage": "GlobalVarConfig::newInstance", "templatestyles": "GlobalVarConfig::newInstance", "ArticleCreationWorkflow": "GlobalVarConfig::newInstance", "popups": "GlobalVarConfig::newInstance", "visualeditor": "GlobalVarConfig::newInstance", "citoid": "GlobalVarConfig::newInstance", "mobilefrontend": "GlobalVarConfig::newInstance", "minerva": "GlobalVarConfig::newInstance", "textextracts": "GlobalVarConfig::newInstance", "RelatedArticles": "GlobalVarConfig::newInstance", "revisionslider": "GlobalVarConfig::newInstance", "ExternalGuidance": "GlobalVarConfig::newInstance", "mwoauth": "GlobalVarConfig::newInstance", "quicksurveys": "GlobalVarConfig::newInstance", "PageViewInfo": "GlobalVarConfig::newInstance", "ReadingLists": "GlobalVarConfig::newInstance" } ``` It seems a fairly small and arbitrary subset of extensions are using this to create their own copy of GlobalVarConfig, but I can't tell whether this is unguided copy-pasta or adding value for someone. E.g. what is the value today in Cite doing `ConfigFactory::makeConfig('cite')` compared to `getMainConfig()`? Being able to have separate objects and multiple sources of configuration is certainly useful. And being able to read config from Etcd like we do in production already is an example of that. (ConfigFactory is great, I'm not suggesting we change anything about that). But the way some extensions anticipate some imaginary future where extensions might have their own config source, is not serving a clear purpose to me. Especially since afaik it is still to-be-determined how and when that would work. If there is an intentional and tangible benefit from this today, this task will track documenting that as a best-practice to eventually being adopted across the board. I not, I suggest we remove this pattern from the few extensions that accidentally adopted it in favour of using the Config object from the Service container like everything else does.

As part of T187154#6034369 I noticed the following on enwiki in production: ```lang=json "wgConfigRegistry": { "vector": "GlobalVarConfig::newInstance", "cite": "GlobalVarConfig::newInstance", "categorytree": "GlobalVarConfig::newInstance", "timedmediahandler": "GlobalVarConfig::newInstance", "CirrusSearch": "CirrusSearch\\SearchConfig::newFromGlobals", "globalcssjs": "GlobalVarConfig::newInstance", "globaluserpage": "GlobalVarConfig::newInstance", "ApiFeatureUsage": "GlobalVarConfig::newInstance", "templatestyles": "GlobalVarConfig::newInstance", "ArticleCreationWorkflow": "GlobalVarConfig::newInstance", "popups": "GlobalVarConfig::newInstance", "visualeditor": "GlobalVarConfig::newInstance", "citoid": "GlobalVarConfig::newInstance", "mobilefrontend": "GlobalVarConfig::newInstance", "minerva": "GlobalVarConfig::newInstance", "textextracts": "GlobalVarConfig::newInstance", "RelatedArticles": "GlobalVarConfig::newInstance", "revisionslider": "GlobalVarConfig::newInstance", "ExternalGuidance": "GlobalVarConfig::newInstance", "mwoauth": "GlobalVarConfig::newInstance", "quicksurveys": "GlobalVarConfig::newInstance", "PageViewInfo": "GlobalVarConfig::newInstance", "ReadingLists": "GlobalVarConfig::newInstance" } ``` It seems a fairly small and arbitrary subset of extensions are using this to create their own copy of GlobalVarConfig, but I can't tell whether this is unguided copy-pasta or adding value for someone. E.g. what is the value today in Cite doing `ConfigFactory::makeConfig('cite')` compared to `getMainConfig()`? Being able to have separate objects and multiple sources of configuration is certainly useful. And being able to read config from Etcd like we do in production already is an example of that. (ConfigFactory is great, I'm not suggesting we change anything about that). But the way some extensions anticipate some imaginary future where extensions might have their own config source, is not serving a clear purpose to me. Especially since 1) afaik it is still to-be-determined how and when that would work and 2) there is no restrictions enforced right now on what this object should or shouldn't be capable of. That is, there is nothing stopping Cite from using its copy of the Config to also read out core configuration variables. I've already seen developers be confused by this, thinking the local object should be used for all config keys, including when you need those from core. If there is an intentional and tangible benefit from this today, this task will track documenting that as a best-practice to eventually being adopted across the board. I not, I suggest we remove this pattern from the few extensions that accidentally adopted it in favour of using the Config object from the Service container like everything else does.

As part of T187154#6034369 I noticed the following on enwiki in production: ```lang=json "wgConfigRegistry": { "vector": "GlobalVarConfig::newInstance", "cite": "GlobalVarConfig::newInstance", "categorytree": "GlobalVarConfig::newInstance", "timedmediahandler": "GlobalVarConfig::newInstance", "CirrusSearch": "CirrusSearch\\SearchConfig::newFromGlobals", "globalcssjs": "GlobalVarConfig::newInstance", "globaluserpage": "GlobalVarConfig::newInstance", "ApiFeatureUsage": "GlobalVarConfig::newInstance", "templatestyles": "GlobalVarConfig::newInstance", "ArticleCreationWorkflow": "GlobalVarConfig::newInstance", "popups": "GlobalVarConfig::newInstance", "visualeditor": "GlobalVarConfig::newInstance", "citoid": "GlobalVarConfig::newInstance", "mobilefrontend": "GlobalVarConfig::newInstance", "minerva": "GlobalVarConfig::newInstance", "textextracts": "GlobalVarConfig::newInstance", "RelatedArticles": "GlobalVarConfig::newInstance", "revisionslider": "GlobalVarConfig::newInstance", "ExternalGuidance": "GlobalVarConfig::newInstance", "mwoauth": "GlobalVarConfig::newInstance", "quicksurveys": "GlobalVarConfig::newInstance", "PageViewInfo": "GlobalVarConfig::newInstance", "ReadingLists": "GlobalVarConfig::newInstance" } ``` It seems a fairly small and arbitrary subset of extensions are using this to create their own copy of GlobalVarConfig, but I can't tell whether this is unguided copy-pasta or adding value for someone. E.g. what is the value today in Cite doing `ConfigFactory::makeConfig('cite')` compared to `getMainConfig()`? Being able to have separate objects and multiple sources of configuration is certainly useful. And being able to read config from Etcd like we do in production already is an example of that. (ConfigFactory is great, I'm not suggesting we change anything about that). But the way some extensions anticipate some imaginary future where extensions might have their own config source, is not serving a clear purpose to me. Especially since 1) afaik it is still to-be-determined how and when that would work. and 2) there is no restrictions enforced right now on what this object should or shouldn't be capable of. That is, there is nothing stopping Cite from using its copy of the Config to also read out core configuration variables. I've already seen developers be confused by this, thinking the local object should be used for all config keys, including when you need those from core. If there is an intentional and tangible benefit from this today, this task will track documenting that as a best-practice to eventually being adopted across the board. I not, I suggest we remove this pattern from the few extensions that accidentally adopted it in favour of using the Config object from the Service container like everything else does.