@Catrope wrote:

1. [skipFunction].
2. We could add some code to resources/src/codex/codex.js that does something like mw.loader.implement( '@wikimedia/codex-search', … );.

When we met last week, you mentioned the first idea around skipFunction, but not yet the second idea. I think this second one might end up working out even better if we combine it with mw.loader.state(). When the server queues codex it can seed codex-search as being in state loading, similar to what we do with user-specific modules, gadget edit previews, and stylesheets.

Neither of these approach, though, account for lazy mw.loader.using() calls, nor for direct queuing of modules on the server-side outside the would-be mechanism we provide for this. Can you remind me whether this is intended as a transition step or whether the part/full bundling is meant as a mid-long term strategy as well?

Note that we have precedent for such mechanism with OOUI (OutputPage::enableOOUI and state optimisations from T92459).

Moving to our radar for now, with the understanding Roan will lead this and loop me in during code review and/or further conversation on/off-Phab.

If you load codex-search and then codex you still get some duplication - eventually perhaps T225842 will allow there to be codex-search and a private codex-non-search and loading the codex module just loads those two dependencies, so that if you load codex first codex-search is not loaded separately, and if you load codex-search first only the non-search parts are loaded the second time.