Krinkle wrote: >However I do want to emphasise that for importScript in particular, there >is no rush. If we need to keep an alias around indefinitely on most larger >wiki's Common.js, that seems fine. Same for addOnloadHook (though that one >is significantly easier to update). > >The main thing we're trying to clean up here is the dozens of legacy >global functions and variables that are largely unused. Such as >'clientPC', 'ie6_bugs', 'escapeQuotesHTML', 'killEvt' etc. And the >negative performance impact of having to load it before all other modules.
I don't understand this. If your main goal is to remove unused and unneeded legacy global variables and functions, and your examples such as 'ie6_bugs' and 'clientPC' seem like fine kill targets to me, why not just remove that code and leave used/useful code like 'importScript'? I'm somewhat reminded of the minimum supported PHP version discussion and the remark about supporting software that can run on our own servers. While this is not directly analogous, if we're going to put a bunch of shims in place on "large" Wikimedia wikis, why not just keep supporting 'importScript' in wikibits? We can move the code to a more modern location in MediaWiki core, if desired. If Wikimedia wikis are largely unable to do this full migration to updated syntax, it seems pretty unreasonable to expect every other MediaWiki installation to essentially copy and paste some snippet into their "MediaWiki:Common.js" page when updating MediaWiki to 1.28 in order to keep useful functions like 'importScript' working. You note that there's no rush, so why make this extra work for everyone? Can we just kill the largely unused portions of wikibits for now and wait till usage of the other code is acceptably low enough to properly remove? Or could we just have 'importScript' indefinitely be an alias for 'mw.loader.load', etc.? MZMcBride _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
