Repository navigation
App.config conflates bundled defaults with operator config #268
Description
Activity
- added a parent issue
on May 22, 2026 Problems
The proposed solution breaks overrides.
translate_legacy_mfe_configtranslates what we'd get from/api/mfe_config/v1intocommonAppConfigand what we'd get from/api/mfe_config/v1?mfe=name_of_mfeinto app configs.Thoughts
It seems given the current state of things the ideal merge priority is
- Lowest: Bundled app config
- Next: Common app config (what we'd get from
/api/mfe_config/v1) - Highest: App specific override config (what we'd get from
/api/mfe_config/v1?mfe=name_of_mfe).
This means we'd need a good way to differentiate between bundled app configs and app configs that come from a site config (or runtime API endpoint). No solutions are popping to mind but I'm sure it's doable.
Other considerations
I don't think the current state of things is set in stone, so I'd like to consider the big picture a bit.
I think one of the main issues with the current state of things is that pretty much all config ends up in
commonAppConfig(at least when pulling it fromapi/frontend_site_config/v1/).This comes from a translation of
/api/mfe_config/v1where "common" means "not an MFE specific override" as opposed to "this is relevant for multiple apps"I think in a post-legacy-config-translation-layer world I'd want
commonAppConfigto refer to configuration values that are used by multiple apps, and for app-specific config values to come from theappssection of thefrontend_site_configendpoint (DISABLE_ENTERPRISE_LOGINis only used byfrontend-app-authnbut appears incommonAppConfigin my dev env for example).Another "out there" thought would be to just not have the
frontend_site_configendpoint returncommonAppConfigat all and instead just populate all the app specific config blocks (even if that means some values are duped). I'd want to have a sense of our "endgame" vision for the API endpoint before doing that though.- added 2 commits that reference this issue
on May 27, 2026 As discussed in the last FWG meeting, we decided not to make any changes to the architecture. Operators already have existing mechanisms to override commonAppConfig intentionally.
- changed the title
[-]commonAppConfig precedence: should site-wide config override bundled app config?[/-][+]App.config conflates bundled defaults with operator config, so commonAppConfig can never win[/+]on Aug 28, 2026 - changed the title
[-]App.config conflates bundled defaults with operator config, so commonAppConfig can never win[/-][+]App.config conflates bundled defaults with operator config[/+]on Aug 28, 2026 - removed a parent issue
on Aug 28, 2026 - added a parent issue
on Aug 28, 2026 In implementing overhangio/tutor-mfe#328, I realized the ergonomics of overriding shipped defaults was just bad. Reopened and submitted a fix.
🎉 This issue has been resolved in version 2.0.0-alpha.4 🎉
The release is available on:
Your semantic-release bot 📦🚀
Metadata
Metadata
Assignees
Type
Projects
- Status
Description
App.configdoes two unrelated jobs, and that is the bug. It holds the values an app author bundles at build time, and the values an operator supplies throughsite.configor the runtime config API.mergeAppflattens both into one object beforeaddAppConfigsruns, so provenance is lost by the timegetAppConfigresolves anything.The consequence is that every key an app bundles is a key
commonAppConfigcan never supply.getAppConfigmerges withmerge({}, commonAppConfig, appConfigs[id]), so a value an operator sets site-wide loses to whatever the app's author shipped. Overrides are fragile for the same reason: an operator changing one value must spread the app's existing config back in, and forgetting the inner spread silently discards every other default.Flipping the merge order is not the fix.
MFE_CONFIG_OVERRIDESreaches apps through per-appconfig, so the flip breaks a channel operators depend on: edx-platform maps/api/mfe_config/v1ontocommonAppConfigand/api/mfe_config/v1?mfe=<name>onto per-appconfig, and an app-specific override must beat site-wide values.The fix is to stop overloading one field.
App.defaultConfigholds the app author's bundled values and resolves belowcommonAppConfig, which resolves belowconfig. The two fields are held separately, so operator-supplied configuration can never write into an app's bundled defaults. ADR 0017 records the decision and #298 implements it.Apps to update
Bundled defaults move from
configtodefaultConfig:defaultConfig)Checked and needing no change: frontend-app-notifications, frontend-app-instructor-dashboard, frontend-app-base-test, frontend-app-sample.
LLM usage notice
Filed with assistance from Claude.