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.
- Detect the issue and trigger a debug log message. – a464d1d41d69
- Fix known offenders in core, bundled extensions and wmf-production.
- Promote log message from level=debug to level=warning. (Released in 1.29) – 976943c9913b842
- Enforce the restriction with non-fatal error. (Released in 1.29) – ed28e106e366f
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.
- 1.32 Release:
- Deprecate addModuleScripts() in OutputPage/ParserOutput.
- 1.33 Release:
- Remove addModuleScripts() in OutputPage/ParserOutput.
- Remove setModuleScripts() in ResourceLoaderClientHtml. (already deprecated since 1.28)
- Deprecate getModuleScripts() from OutputPage/ParserOutput. (no-op)
- 1.34 Release:
- Remove getModuleScripts() from OutputPage/ParserOutput.