However I do want to emphasise that for importScript in
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.
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.?