Rather than reinventing the loader for wiki pages I think we better ingrate with what we already have.

ie.

mw.loader.wikiLoad( 'User:Liangent/Scripts/a.js' ), which internally will use the same as used for "MediaWiki:Common.js" and "User:Liangent/vector.js"

Regarding mw.loader.pageGo(), you can use an array of modules in mw.loader.load or mw.loader.using.

mw.loader.load( ['jquery.colorUtil', 'jquery.hoverIntent', 'jquery.ui.autocomplete'] );

or:

mw.loader.using( ['jquery.ui.widget', 'jquery.ui.mouse'], function(){

// do fancy stuff with widgets and mice.

});

both only make 1 http request:
mw.loader.pageLoad( ['User:Liangent/Scripts/a.js', 'User:Liangent/Scripts/b.js', 'User:Liangent/Scripts/c.js'] );

Adding a wikiLoad function I think is a great idea that is a must-have. However, again, it should not map to mw.loader.load( http://.org/w/?title=TITLE&action=raw&ctype=text/javascript); but instead really go to the server and minify it like it would do for User:/vector.js or MediaWiki:Common.js

(In reply to comment #1)

mw.loader.wikiLoad( 'User:Liangent/Scripts/a.js' ), which internally will use
the same as used for "MediaWiki:Common.js" and "User:Liangent/vector.js"

They're loaded as modules=site and modules=user, not something generic.

Regarding mw.loader.pageGo(), you can use an array of modules in mw.loader.load

Can modules have parameters (to specify the page names) currently?

However, again, it should not map to mw.loader.load(
http://.org/w/?title=TITLE&action=raw&ctype=text/javascript);

Actually I don't know why we invented this. There's already jQuery.getScript.

(In reply to comment #2)

(In reply to comment #1)

mw.loader.wikiLoad( 'User:Liangent/Scripts/a.js' ), which internally will use
the same as used for "MediaWiki:Common.js" and "User:Liangent/vector.js"

They're loaded as modules=site and modules=user, not something generic.

The backend infrastructure does use a generic interface for loading wiki pages (ResourceLoaderWikiModule.php)

mhershberger wrote:

Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734

See also:

• T27845: Support loading wiki pages through mediaWiki.loader.load()

(Cited from bug 25845 comment #19)

mw.loader.load has 2 purposes:

• On-demand loading of a module registered in ResourceLoader
• On-demand loading of a raw url

I think this is a solid system. And loading wiki pages is not a useful feature.
Instead we should focus on implementing the ability for users to create their
own complete ResourceLoader modules within their own space. Allowing raw
loading of wiki pages (although minified) is barely any improvement over the
current system and doesn't address any of the following issues, which have on
the contrary been solved in ResourceLoader

• Proper caching
• Not loading the same content twice (using dependency lists of modules by a

name instead of direct loading of a script page)

• Concatenation
• Translation
• RTL-support
• more..

The original request "Include the functionality of importScript into
mediaWiki.loader.load" is in my opinion a WONTFIX. Until a proper solution
exists, please use importScript() (or if you need a callback, use
jQuery.getScript(url, callback).

The underlying need however is not a wontfix, but a valid need. Instead of
addressing that by adding support for direct loading of a wiki page to
mw.loader.load is bug 34958 (creation of ResourceLoader modules on a user
level)

See bug 34958 instead.