yeah, that goes for any embedded module for that matter. Anything embedded in the html cannot be removed from the 'load queue' since it's stuck in the HTML, so it needs to be in the top of the document before the first loader.load.

One thing to keep in mind though is that user.tokens depends on 'mediawiki.user' (obviously).

We just need to verify that "mw.loader.implement('user.tokens')" doesn't do anything (i.e. it should not trigger an ajax request to get 'mediawiki.user', because 1) nobody asked for 'user.tokens', so no need to resolve dependencies, 2) because 'mediawiki.user' is expected to be in the next loader.load call

(In reply to comment #1)

yeah, that goes for any embedded module for that matter. Anything embedded in
the html cannot be removed from the 'load queue' since it's stuck in the HTML,
so it needs to be in the top of the document before the first loader.load.

Yup, that's right.

One thing to keep in mind though is that user.tokens depends on
'mediawiki.user' (obviously).

That's not a problem. If we load it inside an implement() call, normal dependency resolution will take care of this.

We just need to verify that "mw.loader.implement('user.tokens')" doesn't do
anything (i.e. it should not trigger an ajax request to get 'mediawiki.user',
because 1) nobody asked for 'user.tokens', so no need to resolve dependencies,

2. because 'mediawiki.user' is expected to be in the next loader.load call

I'm not at all worried about that, that's fundamentally not what implement() does. implement() means "look here's the code for this new module, you may or may not be able to run it now depending on the status of its dependencies".

Okay, so no issues left to resolve.

Looks like first usage has come along. mw.Api module is using this as of r107350.

I'll go ahead and move those to the head and see what happens.

Fixed in r107534