= skin.minerva prefixed modules
We have a pattern in MobileFrontend where we include starter modules such as `skins.minerva.backtotop` and `skins.minerva.newuser` that do something on page load. We also have a mega starter module `skins.minerva.scripts` that does multiple things on page load. What should we do so that we don't have a long list of modules like above? Now that feature flagging is in action, we should consider alternative solutions. Since these scripts don't usually weigh a lot, should we consider loading them in the front end unconditionally and executing them depending on the feature flag. This would also help us clean up SkinMinerva.php that loads modules conditionally, thus reducing cache splits.
Note that on startup we load the following modules:
= mobile. prefixed modules
Currently we load the following non ResourceLoaderImage modules on startup.
Given they are loaded by default it's possible it may be advantageous to package these in a single module (size of startup module/size of resulting JS may be smaller/remove fragmentation of JS files used across pages). We should investigate.
= deferring the load of code
Is there benefit in doing this?
= Questions to answer:
* Why is the existing architecture the way it is?
* Does it still make sense?
* Which modules have side effects (e.g. when loaded make changes to the current page)
* Which modules are used by 2 or more features?
* What are the advantages to merging modules?
* What are the advantages of deferring the loading of code
* Should modules define features or components?
* What code is used outside MobileFrontend? Is there justification for sharing it via its own ResourceLoader module?
* Can skins.minerva.scripts.top and skins.minerva.scripts be merged after recent RL changes? Is there any advantage to having them separate?