Regarding MFE theming:
MFEs do not implement a mechanism like comprehensive theming, but instead we’re trying to break “theming” down into its component parts and make it easy to do the common cases. To that end, here’s the current state of MFE theming:
-
Config - Environment variables can be configured at build time, and are responsible for a number of common needs, like site name, URLs to other services, logo location, etc.
-
Branding - MFEs can be built with a custom brand project forked off of GitHub - edx/brand-openedx. This allows overrides of any SCSS variables defined in the Paragon core stylesheets (along the lines of how Bootstrap generally works).
-
Headers and footers - In some MFEs, can be customized by forking the frontend-component-header or frontend-component-footer repositories and customizing the contents of the components. Unfortunately not all MFEs use these shared headers/footers as of this writing. So long as the new versions maintain the header/footer component APIs (React props and exports), they can be substituted into an MFE by installing them in the MFE at build time, overriding the dependencies for frontend-component-header and frontend-component-footer. This is what’s done on edx.org today.
-
Further customization and extension - MFEs do not today allow for component customization or extensions short of forking the repo. That said, we hope to be using webpack module federation to allow plugins, and a webpack alias mechanism to allow custom component overrides, similar to how we allow header/footer overrides today using npm aliases. Between the two, that would allow “supported” customization through a plugin mechanism, and for those that really need something unexpected, “unsupported” customizations via component overrides.
Happy to give more detail on any of that!