Follows-up
6fa489392815 (T84960), which disabled minification
for 'user.tokens'.
In 2014 'user.tokens' module was changed to change tokens on every page view,
even for the same user within a short period of time. This led to a huge
minify-cache growth, and we subsequently disabled caching for its minification
result.
Since then, we have also done:
* Disable minification for 'user.tokens' more generally, given
that it's just a simple JSON blob and we already pass down the 'debug' mode
flag down to the creation of that blob, so there's virtually nothing to left
to minify.
* Disable minification for mw.config.set(). Config values are exported by
ResourceLoaderClientHtml and not part of any module. Given that since 2015
we minify per-module and not per-response (
b7eb243d92) that means config
data naturally doesn't go through minification, which is good, because
just like for 'user.tokens', the config data is JSON which is already created
without whitespace. Minification would be pointless.
However, 'user.options' is still being minified and cached, and makes up about
25% of the 'resourceloader:minify-js.*' keys in APC on Wikimedia servers.
Unlike 'user.tokens', the minify cache for 'user.options' does actually get
used by subsequent page views from the same user (unless preferences changed).
However, it isn't useful because it's plain JSON and already compressed enough.
Besides, the blob is so small that it's not worth the overhead of cache-checking.
If we would want to minify it, I'd recommend we re-minify each view without cache.
Change-Id: Ic0ffb0e23df9b40e2c1283c89bd876a5c0555951