Thanks for bringing this to wikitech-l.
On Sat, Jan 21, 2012 at 4:25 AM, Mark A. Hershberger <
I adjusted the [[MediaWiki:Gadgets-definition]] on enwiki.beta and let
the people on enwiki know what I had found, but I think this sort of
adjustment will be needed in more places. For proof, just look at
You'll see (or, at least, I see) two un-fulfilled dependencies on
One exception is thrown due to references to code from the "mediawiki.util"
module (missing dependency) and two errors due to missing a dependency on
"mediawiki.user". Which shows that the problem is not limited nor specific
the "mediawiki.util" module.
I've also spotted a fair number of gadgets missing dependencies on
"jquery.cookie" during the tour. Basically any references to module code
written by users that didn't know about dependencies is going to fail. As of
writing there are 115 different modules in core that contain one or more
Some sort of dependency needs to be added on mw.util -- either just
preload it or make it log a message when there is an
dependency on it (and other necessary js dependencies).
I think we should attempt to complete the tour (at least the adding of
dependency information) for all wikis before deployment, that's the only
fix for the problem and should've happened in the first place. If after
deployment it would turn out that there is still a large number of scripts
floating around without dependency info, we could add the most common ones
unconditionally to the pre-load startup stack which currently only contains
"jquery" and "mediawiki".
Such measure should be temporary, because it would cause confusion if some
modules work without dependencies info and others don't. i.e. what if next
is a bug report about another dozen modules that people often use but aren't
declared in their dependencies and causing problems. It should not become
"normal" that code works without declaring dependencies. Especially if new
gadgets are written based on others that don't either. These "copied
are very common, and is how most users learn what is "right". In my
so far (both to good and bad ends).
Or to put it boldly vice versa: It should be perfectly normal for code to
explode if it's missing a dependency (I'd rather have it explode on-save for
it to be fixed right away, then it silently working because another gadget
happens to be loaded first is providing the required module to the scope).
However such explosion (or logging a message as you suggest) about a
too dynamic to extract this information. Objects and functions can be
code can be conditionally loaded, code an be lazy-loaded with inline
dependencies and more.
And most commonly, modules loaded as dependency for one module are also
available to all future modules (i.e. if module A and B both use module C,
only A is declaring it's dependency on C. Then loading A and B will likely
succeed without error because C is only loaded once and when B is executed,
it's already there). To complicate it further, this scenario (only having to
load each module once) is actually a major feature of resource loader, not a
Some examples here may be exaggerated, I'm not saying they are going to
if this and that etc., but I'm being cautious because I'm afraid there's no
harmless way back.
This, plus a message on WP:VPT or the like, would be a way for users and
great way to notify
users of the deprecation from 1.18 to 1.20 (or 1.21) without providing a
horribly shocking experience after we upgrade the cluster.
I agree. I've updated the migration guide with Edokter over the past
including common mistakes and their (simple) solutions. So let's spread the
word about it now. So that it may complete before 1.19 deployment. We
should include in communication that this is required for ResourceLoader
1.17 and becomes extra important with the load queue improvements coming in
1.19. Since faster loading makes race conditions in dependency resolving
likely to fail, that is - if dependencies are not declared for all or only
few of gadgets.