ResourceLoader/Migration guide for extension developers

Target system
You might encounter the following server-side warning in your logs:"Module '{module}' not loadable on target '{target}'."Or this client-side console warning:"Skipped unresolvable module {module}."This most likely it means a module is defined with a  target, but unconditionally enqueued on pages on desktop as well. Using targets in this way is deprecated per T127268 and should be avoided in new code.

Paths forward:


 * Consider whether the code could easily be loaded on desktop without harm (e.g. performance, broken functionality, or duplicate functionality).
 * If the module is a mobile-friendly version of another module, evaluate whether this is truly about form factor and device capabilities versus the layout of the Minerva skin. In general, it is recommended that you combine such features into one module and use  and   for aspects that relate to the skin, and code for narrow viewports or touch events should be run unconditionally regardless of skin or device as anyone may use a narrow window on a large device, or have large devices with touch event support. Set the targets to both   in this case.
 * If the feature exists only for Minerva and has no equivalent for other skins or desktop, move the resources to, and set the targets to both   in this case.
 * If the script bundle is significant in size and the feature is only necessary on mobile browsers but not skin, and dependent on something that can be feature detected on the client, e.g. browser viewport size or touchevents, its best to break out a small module for running conditional loads on the client like so:
 * If the feature requires a specific extension e.g. MobileFrontend, you should conditionally load it based on MobileFrontend on the server side, like so:
 * To condititionally lazy-load something client-side only based on the existence of a module, add something like the below code to your general "init" module. This init module should be shared by your extension as a whole, and added server-side to any page where a lazy-loaded thing may be needed. Both the init module and the lazy-loaded module should be defined with . Remember that it is okay for multiple special pages or hooks to queue the same module name. ResourceLoader will not download or execute any module more than once.

In all of the above options, the outcome for the  property is the same: Set it to both   which reflects what will happen when that property is ignored / no longer supported.

Note, that historically certain extensions have been designed to run only in the mobile domain. These should ideally be rewritten using one of the bullet points above, but as a last resort, the following pattern can be used to check whether MobileFrontend is enabled and a page view is inside the mobile domain:

Crash-course: How to use ResourceLoader
Most code written prior to MediaWiki 1.17, the introduction of ResourceLoader, should continue to work, there are some issues that are specific to the architecture of the system which may need to be resolved.

Review for more examples of module registration and  for more examples of how to add modules to a page.

For now let's start with how to register a module:

Registering a module
To make your resources available to the loader, you will need to register them as a module, telling ResourceLoader what you want to make available and where the files are. Check out ResourceLoader/Developing with ResourceLoader to learn how to do that.

Internationalization
You can access messages specified in your resource module using the  method. This returns a Message object whose output formats can be specified as described here. Example:

""

can accept multiple arguments, with additional arguments being passed to the message function named in the first argument (exactly in the same way as with server-side message functions):

""

Inline JavaScript
In previous versions of MediaWiki, nearly all JavaScript resources were added in the head of the document. With the introduction of ResourceLoader, JavaScript resources are now (by default) loaded at the bottom of the body.

The motivation for this change has to do with the fact that browsers block rendering while a script resource is downloaded and executed (this is because a script can do almost anything to the page). By placing scripts at the bottom, the entire page can be loaded before any scripts are executed, ensuring that all stylesheets and images referenced by the HTML content as well as the CSS can be queued before the browser pauses to execute scripts, thus increasing parallelism, and improving client-side performance. This also ensures readers get earlier access to the articles and start reading.

A side-effect of this change is that scripts that have been injected arbitrarily into the different parts of the body can not depend on functionality provided by regular scripts (which are loaded at the bottom). It may be possible to improve backwards compatibility in the future, but there are no specific plans to do so at this time. We recommend to do javascript bindings from the modules rather than inline.

As of MediaWiki 1.18 there are multiple load queues in ResourceLoader (symbolically named "top" and "bottom"). Modules can set their "position" property (in ) to one of these to force loading in either queue. A good use of a "top" module is styling HTML content generated by PHP. The  and   module are loaded from the top by default and can always be used. The queues and positions were removed in MediaWiki 1.29 (T109837), and everything is now at the "top".

Configuration variables
If you used to insert javascript like: var wgFoo = "bar"; You can now use resource loader to add your variable as a config variable. If the variable is the same for all pages and should be on all pages, use the ResourceLoaderGetConfigVars hook. Otherwise if the variable depends on the current page being viewed you can either use the MakeGlobalVariablesScript hook or if you have an OutputPage object, the addJsConfigVars method. Variables added can be accessed in javascript using

Global scope
As the scripts are loaded at the bottom of HTML, make sure that all OutputPage-generated HTML tags are properly closed. If you are porting JavaScript code to ResourceLoader, make the default outer scope variable declarations explicitly use  as their parent, because the default scope in ResourceLoader is not global (e.g. not a window). Which means that code that previously became global by using  in a   file, is now local. It will only be global if you make it global, by literally attaching it to the window object with.

An even better approach (instead of attaching vars to window) is to convert the existing extension's JavaScript code to an object oriented structure. (or, if the code is mainly about manipulating DOM elements, make a jQuery plugin).

Suppose your current structure looks like this:

In order to keep it working with existing implied globals, replace implied globals with real globals (which it should already be):

To actually port it to an object oriented structure, you'd write something like this:

Special case of external libraries
If you are using an external JavaScript library, which is primarily maintained outside of MediaWiki extension repository, patching as suggested above is undesirable. Instead, you should create an extra JavaScript file where the required variables and functions would be bound via the references to window. Then, when registering ResourceLoaderFileModule you should pass both scripts in one PHP array:

""

This will weld the two scripts together before throwing them into a closure.

should contain assignment statements like this:

""

Some libraries autodetect their environment (AMD, node.js, browser, etc.) and can be mistaken in their choice because of the special environment of ResourceLoader. For instance,  (D3.js version 3) selects a node.js-like environment and exports its main variable   in   (the issue doesn’t appear for  ); in this case,   must have a binding file  :

""