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.
Description
In
runtime/config/index.ts,getAppConfigmergescommonAppConfigand the per-app config like this:Because lodash.merge applies sources left to right, the per-app config wins on overlapping keys. That makes
commonAppConfigact as shared defaults that individual apps can specialize.It's worth considering whether the opposite precedence would better match how
commonAppConfigis actually used.commonAppConfiglives onSiteConfig, 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 incommonAppConfigto 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.