Or let's just build on top of mw.config and deprecate M.getConfig

jgonera wrote:

I'm always worried about modifying the behaviour of the code we don't write ourselves, even if it's a small change.

Let's take wgTitle as an example. I can't imagine now any situation where some MediaWiki JavaScript would want the old wgTItle value, but who knows. Or maybe there's some code that keeps updating wgTitle in a weird way and will override what we set there. It just seems bug prone.

I've just thought we could have a very thin wrapper (yay, another one) whose get() function would first try to return values from our config, and if they weren't present it would return the value from mw.config. This way we could always just use one method of accessing config, but at the same time we wouldn't depend on mw.config internals and the ways it's populated.

We can use https://gerrit.wikimedia.org/r/51604 as a basis

Deprecated getConfig, setConfig and mwMobileFrontendConfig in https://gerrit.wikimedia.org/r/52270

I don't think it's a great idea to have these variables included in every non-mobile page view, it's quite a bit of bloat. Instead, you could call addJsConfigVars() conditionally, based on whether the mobile skin is being used. And you could follow the advice on the doc comment of OutputPage::getJSVars() and move the invariant configuration (wgMFPhotoUploadEndpoint etc.) to the startup module.

Related URL: https://gerrit.wikimedia.org/r/63002 (Gerrit Change I08f91aa6b960d642802463424f83c93f6387f0d1)

Related URL: https://gerrit.wikimedia.org/r/63003 (Gerrit Change I126aadd503d233247b783af7bc4fcf13070a1299)

https://gerrit.wikimedia.org/r/63003 (Gerrit Change I126aadd503d233247b783af7bc4fcf13070a1299) | change APPROVED and MERGED [by jenkins-bot]