Change Details

### Motivation Allow skins to comfortably have more modules at a lower cost. ### Background Right now modules bundles from any any installed skin are available for queuing on a page, depending on, or lazy-loading. This is primarily because skins are treated similarly as extensions. There is technically nothing stopping a skin from registering a generic MW hook and do stuff regardless of which skin is currently used by the user. E.g. logic from any random extension could be merged into a skin repo and still work (//Please don't do this.//) #### Proposal In practice it seems really unlikely that anything outside MonoBook should even have awareness of a module like `skin.monobook.foo` (apart from extensions providing skinStyles). Nothing should depend on those, or queue them for loading on a page, except MonoBook's own code. For the "main" module of a skin (e.g. skin.monobook.styles, skin.vector.styles etc.) there is another proposal already to reduce their registry footprint (T232148). That proposal would make it so that the skin module itself is internally implemented like skinStyles. That is, the module would simply be known as `skin` or `skin.styles` and be defined based on the current skin. That takes care of the "main" module, but a skin can of course have additional modules that are sufficiently large or complex to warrant a separate bundle that is only loaded in some cases. This task proposes that ResourceLoader only include those in the startup registry when in a request context for that skin. This would make it unreliable for anything other than MonoBook to call `addModules( 'skin.monobook.something' )` (doing so would mean it only works on pages rendered in that skin, otherwise the module would not be known). ##### Implementation This would effective feel similar to how illegal dependencies like `startup` are omitted, and personal origin modules, and the mobile/desktop target filtering (T127268). In terms of implementation though, I imagine we'd do it the other way around. Rather than trying to filter them out at the last minute, the internal service wiring for ResourceLoader would make sure to only register them when needed in the first place. (This avoids any need to introduce new mechanisms for tracking which module comes from which skin.json, and also avoids any fragile/confusing reliance on a naming scheme).

### Motivation Allow skins to comfortably have more modules at a lower cost. ### Background Right now modules bundles from any installed skin are available for queuing on a page, depending on, or lazy-loading. This is primarily because skins are treated similarly as extensions. There is technically nothing stopping a skin from registering a generic MW hook and do stuff regardless of which skin is currently used by the user. E.g. logic from any random extension could be merged into a skin repo and still work (//Please don't do this.//) #### Proposal In practice it seems really unlikely that anything outside MonoBook should even have awareness of a module like `skin.monobook.foo` (apart from extensions providing skinStyles). Nothing should depend on those, or queue them for loading on a page, except MonoBook's own code. For the "main" module of a skin (e.g. skin.monobook.styles, skin.vector.styles etc.) there is another proposal already to reduce their registry footprint (T232148). That proposal would make it so that the skin module itself is internally implemented like skinStyles. That is, the module would simply be known as `skin` or `skin.styles` and be defined based on the current skin. That takes care of the "main" module, but a skin can of course have additional modules that are sufficiently large or complex to warrant a separate bundle that is only loaded in some cases. This task proposes that ResourceLoader only include those in the startup registry when in a request context for that skin. This would make it unreliable for anything other than MonoBook to call `addModules( 'skin.monobook.something' )` (doing so would mean it only works on pages rendered in that skin, otherwise the module would not be known). ##### Implementation This would effective feel similar to how illegal dependencies like `startup` are omitted, and personal origin modules, and the mobile/desktop target filtering (T127268). In terms of implementation though, I imagine we'd do it the other way around. Rather than trying to filter them out at the last minute, the internal service wiring for ResourceLoader would make sure to only register them when needed in the first place. (This avoids any need to introduce new mechanisms for tracking which module comes from which skin.json, and also avoids any fragile/confusing reliance on a naming scheme).

### Motivation Allow skins to comfortably have more modules at a lower cost. ### Background Right now modules bundles from any any installed skin are available for queuing on a page, depending on, or lazy-loading. This is primarily because skins are treated similarly as extensions. There is technically nothing stopping a skin from registering a generic MW hook and do stuff regardless of which skin is currently used by the user. E.g. logic from any random extension could be merged into a skin repo and still work (//Please don't do this.//) #### Proposal In practice it seems really unlikely that anything outside MonoBook should even have awareness of a module like `skin.monobook.foo` (apart from extensions providing skinStyles). Nothing should depend on those, or queue them for loading on a page, except MonoBook's own code. For the "main" module of a skin (e.g. skin.monobook.styles, skin.vector.styles etc.) there is another proposal already to reduce their registry footprint (T232148). That proposal would make it so that the skin module itself is internally implemented like skinStyles. That is, the module would simply be known as `skin` or `skin.styles` and be defined based on the current skin. That takes care of the "main" module, but a skin can of course have additional modules that are sufficiently large or complex to warrant a separate bundle that is only loaded in some cases. This task proposes that ResourceLoader only include those in the startup registry when in a request context for that skin. This would make it unreliable for anything other than MonoBook to call `addModules( 'skin.monobook.something' )` (doing so would mean it only works on pages rendered in that skin, otherwise the module would not be known). ##### Implementation This would effective feel similar to how illegal dependencies like `startup` are omitted, and personal origin modules, and the mobile/desktop target filtering (T127268). In terms of implementation though, I imagine we'd do it the other way around. Rather than trying to filter them out at the last minute, the internal service wiring for ResourceLoader would make sure to only register them when needed in the first place. (This avoids any need to introduce new mechanisms for tracking which module comes from which skin.json, and also avoids any fragile/confusing reliance on a naming scheme).