commonAppConfig precedence: should site-wide config override bundled app config?

[arbrandes]

Description

In runtime/config/index.ts, getAppConfig merges commonAppConfig and the per-app config like this:

return merge({}, commonAppConfig, appConfigs[id]);

Because lodash.merge applies sources left to right, the per-app config wins on overlapping keys. That makes commonAppConfig act as shared defaults that individual apps can specialize.

It's worth considering whether the opposite precedence would better match how commonAppConfig is actually used. commonAppConfig lives on SiteConfig, which is the operator-controlled surface for a given deployment. Per-app configs, by contrast, typically ship bundled with the app itself. Under the current ordering, a value an operator sets in commonAppConfig to apply site-wide (analytics keys, branding, feature flags, shared endpoints) silently loses to whatever the app's author bundled, which is the opposite of what an operator overriding "common" config would reasonably expect.

Flipping the order to merge({}, appConfigs[id], commonAppConfig) would make site-wide config authoritative across apps, with per-app config acting as the default an operator can override. That framing also reads more naturally given the name: "common" suggests site-wide policy, not "defaults the app can ignore."

This is a behavior change, so it deserves a deliberate decision rather than a quiet flip. Filing here to surface the tradeoff and get input on which semantics the project wants to commit to.

LLM usage notice

Filed with assistance from Claude.

[brian-smith-tcril]

Problems

The proposed solution breaks overrides.

translate_legacy_mfe_config translates what we'd get from /api/mfe_config/v1 into commonAppConfig and what we'd get from /api/mfe_config/v1?mfe=name_of_mfe into 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 from api/frontend_site_config/v1/).

This comes from a translation of /api/mfe_config/v1 where "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 commonAppConfig to refer to configuration values that are used by multiple apps, and for app-specific config values to come from the apps section of the frontend_site_config endpoint (DISABLE_ENTERPRISE_LOGIN is only used by frontend-app-authn but appears in commonAppConfig in my dev env for example).

Another "out there" thought would be to just not have the frontend_site_config endpoint return commonAppConfig at 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.