Change Details

This follows-up on 80e5b160e0985, which removed the last use of these methods in core. The addModuleScripts() and addModuleStyles() methods have very different histories and use cases, none of which **actually** relate to the need to load only part of a module. Both methods were originally introduced for the `user` and `site` modules, and have always been used in such a way that does load both the styles and scripts of the modules involved. The only reason they were loaded, in two parts, with these methods is not because of *what* the methods load, but because of *how* the methods load the specified code. ### addModuleStyles() This method is special because it loads styles using a `<link rel=stylesheet>` tag, instead of using JavaScript. As such, it is intended for styles that relate to skin and page content. As side-effect of this important loading method, if the module were to contain JavaScript code as well, it would be ignored. As of T87871 and T92459, doing so now produces a warning. From T92459: * {icon check color=green} Detect the issue and trigger a debug log message. – a464d1d41d69 * {icon check color=green} Fix known offenders in core, bundled extensions and wmf-production. * {icon check color=green} Promote log message from level=debug to level=warning. (Released in 1.29) – 976943c9913b842 * {icon check color=green} Enforce the restriction with non-fatal error. (Released in 1.29) – ed28e106e366f As it stands, we want to keep the method given it has important semantic differences that cannot be merged into `addModules()` without confusion. For example, loading a module as a stylesheet means it cannot have dependencies due to being hardcoded into the page. It also allows developer to retain control whether or not to load a module as a stylesheet. In most cases, style modules intended for JavaScript also have scripts. But it is possible for JS module to depend on a styles-only module that is only needed by JS, which should not be loaded as a blocking stylesheet. As such, we do not want to automatically load styles-only modules a blocking stylesheet via addModules(). Instead we'll keep using addModuleStyles() for that purpose. ### addModuleScripts() This method is special because, unlike regular module loading, this method will transport the script source to the client without closure wrapping, without `mw.loader` wrapping, without localStorage caching, and thus in the **global scope**. It's sole purpose was to allow loading of legacy user scripts in the global scope. However, that use case has since been solved by other means. Leaving no further use of this system. * {icon check color=green} Release N: ** Deprecate `addModuleScripts()` in OutputPage/ParserOutput. * [ ] Release N+1: ** Remove `addModuleScripts()` in OutputPage/ParserOutput. ** Remove `setModuleScripts()` in ResourceLoaderClientHtml. (already deprecated since 1.28) ** Deprecate `getModuleScripts()` from OutputPage/ParserOutput. (no-op) * [ ] Release N+2: ** Remove `getModuleScripts()` from OutputPage/ParserOutput.

This follows-up on 80e5b160e0985, which removed the last use of these methods in core. The addModuleScripts() and addModuleStyles() methods have very different histories and use cases, none of which **actually** relate to the need to load only part of a module. Both methods were originally introduced for the `user` and `site` modules, and have always been used in such a way that does load both the styles and scripts of the modules involved. The only reason they were loaded, in two parts, with these methods is not because of *what* the methods load, but because of *how* the methods load the specified code. ### addModuleStyles() This method is special because it loads styles using a `<link rel=stylesheet>` tag, instead of using JavaScript. As such, it is intended for styles that relate to skin and page content. As side-effect of this important loading method, if the module were to contain JavaScript code as well, it would be ignored. As of T87871 and T92459, doing so now produces a warning. From T92459: * {icon check color=green} Detect the issue and trigger a debug log message. – a464d1d41d69 * {icon check color=green} Fix known offenders in core, bundled extensions and wmf-production. * {icon check color=green} Promote log message from level=debug to level=warning. (Released in 1.29) – 976943c9913b842 * {icon check color=green} Enforce the restriction with non-fatal error. (Released in 1.29) – ed28e106e366f As it stands, we want to keep the method given it has important semantic differences that cannot be merged into `addModules()` without confusion. For example, loading a module as a stylesheet means it cannot have dependencies due to being hardcoded into the page. It also allows developer to retain control whether or not to load a module as a stylesheet. In most cases, style modules intended for JavaScript also have scripts. But it is possible for JS module to depend on a styles-only module that is only needed by JS, which should not be loaded as a blocking stylesheet. As such, we do not want to automatically load styles-only modules a blocking stylesheet via addModules(). Instead we'll keep using addModuleStyles() for that purpose. ### addModuleScripts() This method is special because, unlike regular module loading, this method will transport the script source to the client without closure wrapping, without `mw.loader` wrapping, without localStorage caching, and thus in the **global scope**. It's sole purpose was to allow loading of legacy user scripts in the global scope. However, that use case has since been solved by other means. Leaving no further use of this system. * {icon check color=green} Release 1.32: ** Deprecate `addModuleScripts()` in OutputPage/ParserOutput. * [ ] Release >= 1.33: ** Remove `addModuleScripts()` in OutputPage/ParserOutput. ** Remove `setModuleScripts()` in ResourceLoaderClientHtml. (already deprecated since 1.28) ** Deprecate `getModuleScripts()` from OutputPage/ParserOutput. (no-op) * [ ] Release +1: ** Remove `getModuleScripts()` from OutputPage/ParserOutput.

This follows-up on 80e5b160e0985, which removed the last use of these methods in core. The addModuleScripts() and addModuleStyles() methods have very different histories and use cases, none of which **actually** relate to the need to load only part of a module. Both methods were originally introduced for the `user` and `site` modules, and have always been used in such a way that does load both the styles and scripts of the modules involved. The only reason they were loaded, in two parts, with these methods is not because of *what* the methods load, but because of *how* the methods load the specified code. ### addModuleStyles() This method is special because it loads styles using a `<link rel=stylesheet>` tag, instead of using JavaScript. As such, it is intended for styles that relate to skin and page content. As side-effect of this important loading method, if the module were to contain JavaScript code as well, it would be ignored. As of T87871 and T92459, doing so now produces a warning. From T92459: * {icon check color=green} Detect the issue and trigger a debug log message. – a464d1d41d69 * {icon check color=green} Fix known offenders in core, bundled extensions and wmf-production. * {icon check color=green} Promote log message from level=debug to level=warning. (Released in 1.29) – 976943c9913b842 * {icon check color=green} Enforce the restriction with non-fatal error. (Released in 1.29) – ed28e106e366f As it stands, we want to keep the method given it has important semantic differences that cannot be merged into `addModules()` without confusion. For example, loading a module as a stylesheet means it cannot have dependencies due to being hardcoded into the page. It also allows developer to retain control whether or not to load a module as a stylesheet. In most cases, style modules intended for JavaScript also have scripts. But it is possible for JS module to depend on a styles-only module that is only needed by JS, which should not be loaded as a blocking stylesheet. As such, we do not want to automatically load styles-only modules a blocking stylesheet via addModules(). Instead we'll keep using addModuleStyles() for that purpose. ### addModuleScripts() This method is special because, unlike regular module loading, this method will transport the script source to the client without closure wrapping, without `mw.loader` wrapping, without localStorage caching, and thus in the **global scope**. It's sole purpose was to allow loading of legacy user scripts in the global scope. However, that use case has since been solved by other means. Leaving no further use of this system. * {icon check color=green} Release N:1.32: ** Deprecate `addModuleScripts()` in OutputPage/ParserOutput. * [ ] Release N+1:>= 1.33: ** Remove `addModuleScripts()` in OutputPage/ParserOutput. ** Remove `setModuleScripts()` in ResourceLoaderClientHtml. (already deprecated since 1.28) ** Deprecate `getModuleScripts()` from OutputPage/ParserOutput. (no-op) * [ ] Release N+2:+1: ** Remove `getModuleScripts()` from OutputPage/ParserOutput.