The main part of this (split /resources up into library and non-library directories) has been done. Other parts (update libraries to most recent versions after testing) are done from time to time anyway – the preparatory testing for the jQuery 1.8.x -> 1.11.x work has been going on for months now, for instance – and moving our internal libraries that might be of use to others out of the MW core repo and into their own repo seems like a no-brainer.
Talk:Requests for comment/Isolate custom jQuery libraries
Nearly all WMF wikis load TimedMediaHandler and on 'BeforePageDisplay' it adds module 'mw.PopUpMediaTransform', which depends on Spinner.js, an earlier version of fgnass's code. TMH uses it to render a fairly large "loading" animation over media players.
It would be nice to only use one spinner library. bug 55550 is to reduce resource code loaded by TMH and MwEmbedSupport. A lot of extensions roll their own spinner, including I think ApiSandbox, Flow, LiquidThreads, UploadWizard...
BTW WMF still has a lot of code using (window.)injectSpinner() and removeSpinner from wikibits.js, even though it's deprecated.
This post was posted by SPage (WMF), but signed as S Page (WMF).
BTW: See also bugzilla:56201.
Global injectSpinner() and removeSpinner() no longer exist now. (I hope that whoever was using them no longer does ;) )
Another problem we have is the 'mediawiki' vs 'jquery' divide, with the implication that all core things should go in the former, and all outside things in the latter. This might be a surprise to some :P, but JS libraries which don't use jQuery exist! – one such library which we already have in core is QUnit (misleadingly named 'jquery.qunit.js' right now), another would be Underscore/Lo-Dash should we decide to include it. (We also have several custom scripts in the 'jquery' namespace which barely use jQuery, sometimes just extending its global object – jquery.byteLength, jquery.client, …)
Quoting this RFC:
- 3rd party libraries and MediaWiki specific libraries should be isolated from each other:
- resources/jquery/ should be restricted to 3rd party unmodified libraries.
- Custom and forked jQuery libraries should go into another directory such as jquery.custom or jquery.local.
- Libraries integrated directly with MediaWiki's mediaWiki.* or dependent on its environment should go in another directory such as mediawiki.jquery.
While I'm all for the general direction, I'd suggest a slightly different way to go about it: let's create 'libs' and 'core' directories inside resources/.
'libs' would include anything that is (or started as) a third-party library and that has an upstream that could be linked to; forks with minor changes would go there too (with the restrictions as mentioned in the RFC, and unless the fork is a large rewrite). 'core' would include libraries specific to MediaWiki itself; both ones directly tied in into it (mediawiki.api, mediawiki.special.*, …) and ones which were just created here, but could conceivably be useful elsewhere with none or minor modifications (all of our custom stuff now sitting in resources/jquery/, mediawiki.ui).
The 'libs' directory could contain libraries managed with some dependency manager, or git submodules, or straight copied files (but that's out of scope here). The 'core' directory would contain regular files with no magic. If we ever split a library out (as suggested by the RFC), it would just be moved to the other directory (module name could stay the same).
Both 'libs' and 'core' could be further subdivided, but in libs' case I'd rather do away with things like the 'jquery' directory containing everything with 'jQuery' in its name and just place the files directly there. We would instead have directories (or submodules, whatever…) for libraries like jquery.chosen or jquery.tipsy, which come with their own images, styles or licenses. In core's case the current division of mediawiki.* libraries makes sense to me (plus a new directory called 'jquery' would likely appear with our custom jQuery scripts).
Thoughts?
Sorry if it was ambiguous but when I said "resources/jquery/ should be restricted to 3rd party unmodified libraries." I was not implying that everything should go into the jquery folder. I said that because as of writing it resources/jquery/ was the only folder where we foolishly threw 3rd party libraries, forks, and MediaWiki specific code. For non-jquery 3rd party libraries under the old/current resources/*/ folders my thoughts were then that each major library should have it's own folder, resources/underscore/ resources/lodash/ and MediaWiki stuff naturally come in resources/mediawiki.*/ folders, not that random 3rd party libraries go in resources/jquery/.
Just for the record, our copies being out of date with the upstream repository on itself is in my opinion not a direct problem we can address. Especially in case of jQuery core and jQuery UI this is a conscious and intentional decision as newer major versions break compatibility (afaik we are or should be up to date with the latest minor updates). Especially considering wide usage in gadgets, this is a though problem to solve that we don't have much experience in. Compatibility wise we're still in the very first iteration of MediaWiki's front-end (ResourceLoader, mw.config, jQuery and more happened, but we still support legacy globals, wikibits and jQuery 1.8).
The first turn over started in MediaWiki 1.17 with the introduction of ResourceLoader and the deprecation of pretty much all the legacy code from before that. However we haven't removed that yet.
Only recently have we started to more visibly deprecate stuff with an mw.log.deprecate accessor wrapper (possibly replacing with dummy values) to make it easier to recognise use of deprecated interfaces.
This is the first major move towards a more close loop with gadget authors in the community to keep up while we move thigns forward and take on responsible maintainership of different gadgets. And of course the Resource walker tour to identify outdated, broken and/or unmaintained gadgets that have been left behind since at least 2010 from before MediaWiki 1.17, which is still on-going and leaves much work to be done still.
That's not to say we should never upgrade, it's just going to take a while to get this first cycle finished. From there we can start cycling faster and catch up.
This might be a little out of scope for the RFC, so I'm commenting here instead of inline. You mention Underscore.js in a few places – has anybody considered including it in core, preferably as a default library like jQuery? Because I'm getting really tired of not having a sane consistent set of functions for "advanced" features like whitespace trimming, regex escaping or a sane map() function :)
I'm in favour of including either Underscore.js or Lo-Dash. I've tried using them a few times recently and they've worked out quite well. I started out with Underscore. Lo-Dash is also popular on node, Grunt actually uses it.
I wouldn't say "default library" myself. Though that stems from my current opinion of not entirely liking the way we don't declare 'jquery' on things that use it. Also given the possibility of an Underscore vs. Lo-Dash debate it's probably a good idea to explicitly declare the name of the library and use an IIFE that maps either underscore -> _ or lodash -> _ (running either one or both in noConflict mode may be reasonable). That way if anything happens it's not too hard to slowly migrate everyone to the other library.
((Side topic we may also want to look at Lazy.js. Not as default in any way. But occasionally we may run into cases we are doing things that do a number of sequence operations on a large list of items. In which case it would be useful to include Lazy.js and it's different API for that specific use.))
Just to cut you off though. Underscore.js/Lo-Dash provide those map, each, filter, etc... array methods (as well as a bunch of bonus stuff for objects and functions) however they don't include any string functions.
String functions are provided by the Underscore.string.js library – which does work with both Underscore.js and Lo-Dash – which is 3rd party and not made by the authors of either Underscore.js or Lo-Dash. So it may not be as popular as the other two (though I think Grunt still uses it with Lo-Dash). There is a bug or maybe two we may want to push to have fixed before we start using Underscore.string.
There are no older topics