Hi,
Thanks for bringing this to wikitech-l.
On Sat, Jan 21, 2012 at 4:25 AM, Mark A. Hershberger < mhershberger@wikimedia.org> wrote:
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 http://de.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Hauptseite?debug=true in FireBug.
You'll see (or, at least, I see) two un-fulfilled dependencies on mw.util.
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 to 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 javascript files.
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 unenumerated 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 real 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 up 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 habbits" are very common, and is how most users learn what is "right". In my perception this is how the vast majority of javascript code has been saved to wiki pages 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 dependency missing is unlikely to occur when it should. JavaScript is simply too dynamic to extract this information. Objects and functions can be aliased, 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, but 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 bug.
Some examples here may be exaggerated, I'm not saying they are going to happen 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
gadget authors to update their javascript. It be a 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[1] with Edokter over the past week, including common mistakes and their (simple) solutions. So let's spread the word about it[1] now. So that it may complete before 1.19 deployment. We should include in communication that this is required for ResourceLoader since 1.17 and becomes extra important with the load queue improvements coming in 1.19. Since faster loading makes race conditions in dependency resolving more likely to fail, that is - if dependencies are not declared for all or only few of gadgets. Thanks, - Krinkle
[1] https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(users%29