Hi, Thanks for bringing this to wikitech-l. On Sat, Jan 21, 2012 at 4:25 AM, Mark A. Hershberger < mhershberger(a)wikimedia.org&gt; wrote: 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 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 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

On Wed, Jan 25, 2012 at 7:35 AM, Rob Lanphier &lt;robla(a)wikimedia.org&gt; wrote: These were fixed a little while ago by loading mw.util and its dependencies early. This means that any JS that uses mw.util but doesn't explicitly declare this dependency will continue to work, because mw.util will be one of the first things to be loaded (before any on-wiki JS) and will always be loaded regardless of whether any module indicates they need this or not. However, ideally people shouldn't rely on this behavior (it probably won't be this way forever, as we'll try to get rid of these early-loading privileges where we can), and should always list all dependencies a gadget or user script uses. The following modules are loaded early and are always present: mediawiki.page.startup mediawiki.legacy.wikibits mediawiki.legacy.ajax (pending merge of r111034 into 1.19) mediawiki.util (listed separately, but would be loaded anyway because page.startup depends on it) Additionally, the following modules are also loaded early and always because one of the three modules above depends on them: jquery.client (dependency of mw.page.startup and mw.util) jquery.cookie (dependency of mw.util) jquery.messageBox (dependency of mw.util) jquery.mwExtension (dependency of mw.util) You should rely even less on this second set of modules being magically present, because these dependencies might be factored out and disappear unannounced. I believe this should address everyone's concerns about JS breakage in 1.19 (I've put in workarounds for every kind of breakage I've seen or could think of), but if there are any outstanding issues or concerns feel free to talk to me on-list or off-list. Roan