Last modified: 2014-04-09 22:03:36 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T65674, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 63674 - Document which modules do not need to be added to the dependencies of other modules
Document which modules do not need to be added to the dependencies of other m...
Product: MediaWiki
Classification: Unclassified
Documentation (Other open bugs)
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: documentation
  Show dependency treegraph
Reported: 2014-04-08 13:19 UTC by Helder
Modified: 2014-04-09 22:03 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Helder 2014-04-08 13:19:13 UTC
Could someone complement the docs[1] with information on which ResourceLoader modules are supposed to be always loaded by default?

I keep forgetting this, and others might benefit from it.

See e.g. the case of "user.options" on [2] and Krinkle's comment on Change-Id: Ia2c87a32f692da2347ad670cdbcf6d6e6d171f15

Comment 1 Bartosz Dziewoński 2014-04-09 18:17:50 UTC
Krinkle has just posted an excellent comment on [[en:MediaWiki talk:Common.js#Protected edit request on 7 April 2014]], reproducing here for posterity:


Let me clarify. There's three things at play:

* The mediawiki base module (`mediawiki`). This one can't be declared
  as dependency (and doesn't have to be) because it is the base module
  that actually defines `mw.loader` itself. If memory serves, it
  currently defines `mw.Map`, `mw.config`, `mw.messages`,
  `mw.Message`, `mw.loader`, `mw.html`, `mw.hook` and a few
  miscellaneous methods. None of these have their own module (it's not
  that you can't or shouldn't depend on it, they simply don't exist as
  a module, e.g. there is no such module as `mediawiki.config` or
  `mediawiki.html`, it would throw "Unknown dependency" if you try).
* Page modules: There are various modules that are loaded by default
  on a page (either because the Skin needs it, or because we use it
  for enhancing page content, or because an extension added it to the
  load queue etc.). This usually includes `mediawiki.user`,
  `mediawiki.legacy.wikibits` and others. Though these are loaded by
  default, they absolutely must not be assumed as being available at
  all times. If you use `mw.user`, you *have* to declare that
  dependency. Two reasons for this:
  1) The default list can change (either in general or for some
     pages). There is nothing that says they will always be loaded,
     they are loaded because some part of the application uses them
     (just like your preferences panel will add a gadget if you tell
     it to, and if that gadget is on every page and loads `mw.Title`
     then that module will be on every page, but that's just a
     coincidence). They are not part of the "this is always available,
     use freely" and never have been.
  2) While they are loaded by default, even now things load in
     parallel (this is by design). If you want your code to execute
     after "mediawiki.user" has finished loading, you have to indicate
     this through a dependency or else there will be race conditions
     where mw.user is still undefined and your code will fail.
* Globally embedded page modules. These modules (such as
  `user.options`) are embedded within the page for security and/or
  performance reasons. Since they execute synchronously and are
  embedded before any load queue, these not only load by default but
  also "finish" loading before any module, gadget or otherwise starts
  loading. Which means technically you can get away with not
  specifying `user.options` as a dependency because it's impossible
  for them not to be there. However, once again, do not rely on the
  arbitrary implementation detail that this particular module is being
  embedded right now.

In short: Just declare all your direct module dependencies and let
ResourceLoader do its job.

Comment 2 Bartosz Dziewoński 2014-04-09 18:19:56 UTC
So, to sum up: there are exactly two such modules, 'jquery' and
'mediawiki' (and in fact since Ic8b4ed45 in core, PHP unit tests will
fail if you try to create a module that depends on them server-side).
All other ones should be explicitly declared as dependencies, even if
the code works when you don't.
Comment 3 Bartosz Dziewoński 2014-04-09 18:31:48 UTC
I added this information to the page: – feel free to improve it if it's unclear. Thanks :)

Note You need to log in before you can comment on or make changes to this bug.