This is an approach we previously rejected, but in light of the discussion on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/992831 we'd like to come back to it and prototype it, to see how feasible (or bad) it would be.

Basically, we would prototype the approach laid out in T344386#9153813, but without private modules and without the alias functionality. In detail, that would mean:

• Dynamically generate module registrations, with one module for each entry in Codex's manifest.json (one script-only module and one style-only module for each component, and one script-only module for each composable and each chunk). These would have names like @wikimedia/codex/CdxButton, @wikimedia/codex/CdxButton-styles, @wikimedia/codex/useModelWrapper or @wikimedia/codex/_buttonHelpers.
• The style modules would point to different files depending on the skin and direction
• The script modules need to do something to redirect calls to require( './CdxButton.js' ) to require( '@wikimedia/codex/CdxButton' ). If we introduce an aliases feature, we could use that, but in the meantime, they could just add a wrapper file to their packageFiles that defines the contents of CdxButton.js as module.exports = require( '@wikimedia/codex/CdxButton' ); (the dependency deduplication patch uses this trick too)
• CodexModule would then interpret the existing codexComponents setting, and add a virtual codex.js file as it currently does, but that file would just be a wrapper around each of these smaller modules, e.g. module.exports = { CdxButton: require( '@wikimedia/codex/CdxButton' ) };. It would also need to add the smaller modules (e.g. @wikimedia/codex/CdxButton) to the module's dependencies.

We previously avoided this approach due to the large number of modules it would involve creating (79 at present), but we want to prototype it anyway to evaluate if the increased number of modules would be worth it compared to T350056, which is more complex and less good at actually deduplicating things.