### Announcement and current proposal
See Wikitech: <https://lists.wikimedia.org/pipermail/wikitech-l/2016-May/085479.html>
For migration of site and user module:
>
> Currently:
> * Output A: `<link modules=site>` (loads site styles), `mw.loader.load('site')` (loads site scripts, and styles a second time)
>
> Step 1:
>
> * Create 'site.styles'. – <https://gerrit.wikimedia.org/r/292972 >
> * Start tracking state of pure style modules. – <https://gerrit.wikimedia.org/r/288026>
> * Behaviour of Output A unchanged.
> * New Output B: `<link modules=site.styles>`, `state(site.styles = ready)`, `mw.loader.load('site')` (still loads styles twice)
>
> Step 2:
>
> * Remove styles from 'site', make 'site' depend on 'site.styles' (only affects startup module). – <https://gerrit.wikimedia.org/r/292973>
> * No change in HTML output.
> * Output B no longer ends up loading styles twice.
### Original proposal
> We'll need to grandfather in the legacy 'user' and 'site' module that need global scope execution, and load stylesheets separately. For anything else, addModuleStyles should throw (or ignore and log warning) for any module that does not purely have styles.
>
> So it should not allow modules with scripts or dependencies.
>
> @TrevorParscal, @Catrope and I discussed this a few weeks ago and decided to go in this direction. It will also serve to fulfill a request made to the Frontend Standard Group for future flexibilities and performance improvements (Phabricator tasks?) that depend on this.
>
> From what I recall the implementation would add methods to the ResourceLoaderModule base class to indicate whether a module has (only) styles (possibly more generic with ability to detect other purity as well).
>
> Modules default to not allowing `addModuleStyles` in the new system and require implementing this new method.
>
> For simple modules like ResourceLoaderFileModule we'll provide the method, as it can be determined from the constructor without any computation. For code-generating modules it can not be automatically determined if getStyles/getScripts will provide something or not. Those will need to implement the method if they need `addModuleStyles`.
>
> As a result of this distinction, we can safely output `mw.loader.state( .., "ready" )` for modules loaded via `addModuleStyles`.
This will fix bugs such as:
* {T112552}
* {T117772}
This will enable:
* {T87871}
* {T108590}
* {T42284}
### Status
[x] Implement.
[x] Monitor resourceloader logs from Jenkins, Beta and mwdebug requests in production for any "Unexpected general module "{module}" in styles queue." - fix any violations in core and extensions.
[x] Release deprecation warning in 1.29
[] Once low enough for Gadgets as well, change Gadgets extension to no longer try to load modules twice, but instead default to "general" (addModules) for modules that contain both scripts and styles.
[] After that, there should be no warnings left in the logs. At this point we can consider changing addModuleStyles() in MediaWiki to no longer load such module but instead ignore with non-fatal error, or throw exception. (Release in 1.30?)
### Logstash warnings
* [x] Unexpected general module "ext.RevisionSlider.lazy" in styles queue. T164893
* [x] Unexpected general module "mobile.messageBox" in styles queue. T164892
* [x] Unexpected general module "mobile.mainMenu" in styles queue. T164892
* [x] Unexpected general module "ext.codereview.local" in styles queue. <https://gerrit.wikimedia.org/r/352990>
* [x] Unexpected general module "ext.templateData" in styles queue. <https://gerrit.wikimedia.org/r/352997>
* [x] Unexpected general module "ext.wikihiero.Special" in styles queue. <https://gerrit.wikimedia.org/r/355439>
* [ ] Unexpected general module "ext.math.scripts" in styles queue. T158376
* [ ] Unexpected general module "ext.proofreadpage.page" in styles queue.
* [ ] Unexpected general module "ext.proofreadpage.page.edit" in styles queue.