ResourceLoader sorts the modules for stylesheets added with addModuleStyles alphabetically ignoring dependencies.
In other words if you create the module 'a' and make it depend on the module 'b'. And then do $out->addModuleStyles( 'b' ); $out->addModuleStyles( 'a' );. ResourceLoader will load 'a' first and then load 'b', even though both the dependencies and addModuleStyles say that's wrong.
Skins use addModuleStyles to add skin styles to the page. The setupSkinUserCss was crafted previously so that addStyle could be used in the correct order by overriding the function and using parent::setupSkinUserCss at the right spots. And this works for subskins too since they can let the parent skin add it's styles before adding their own styles. However the alphabetical sorting done by RL goes and undoes any precise ordering required by that.
This is problematic for the creation of subskins. If you create a 'skin.foo' that depends on 'skin.vector' and setup setupSkinUserCss properly RL will go and put skin.vector after your
The only reason every skin isn't already broken by the shared styles is that 'mediawiki.legacy.' alphabetically sorts before 'skin.'. If we fixed that and started using 'skins.common.' some skins could start to break.
Also note that most skins use mediawiki.legacy.shared and mediawiki.legacy.commonPrint which are not added by any core or third party skin to the dependency setup of the skin's module. So even if we fix this to not sort things before the things they depend on it would be best to make sure we also fix it to take addModuleStyles into account.
The ideal situation of course is to fix addModules to know that some modules should not be loaded by JS (another key on the module registration) and just use addModules inside of initPage, deprecating setupSkinUserCss for anything besides addStyle usage (eg: IE stylesheets) and old skin compatibility.
But we have skins that use addModuleStyles right now so we'll need to fix this bug at minimum for compatibility.
Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61577