Page MenuHomePhabricator

[Spike] Explore one-module-per-component approach to code splitting
Open, Needs TriagePublic


This is an approach we previously rejected, but in light of the discussion on 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.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Another issue with this approach that we'd have to explore in a prototype is how dependencies between style modules would work. These dependencies would be handled correctly when these modules are loaded in the normal, non-render-blocking way (through addModules() or as the dependencies of other modules), but addModuleStyles() does not consider dependencies (intentionally, see T191652#4117599). So calling addModuleStyles() on a module that uses CodexModule to pull in styles for various Codex components would not work, and trying to make it work would require solving the caching-related issues presented in T191652#4117599.