Rename Edge Config to Global Config across examples#1538
Conversation
|
You must have Developer access to commit code to Vercel Examples on Vercel. If you contact an administrator and receive Developer access, commit again to see your changes. Learn more: https://vercel.com/docs/accounts/team-members-and-roles/access-roles#team-level-roles |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Deployment failed with the following error: Learn More: https://vercel.com/docs/concepts/projects/project-configuration |
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
| "@tailwindcss/typography": "0.5.16", | ||
| "@vercel/edge": "1.2.1", | ||
| "@vercel/edge-config": "1.4.3", | ||
| "@vercel/global-config": "1.5.0", |
There was a problem hiding this comment.
@vercel/global-config was bumped to 1.5.0/^1.5.0 across 13 package.json files, but that version is not published on npm (only 1.4.3 exists), breaking pnpm install.
| } | ||
|
|
||
| if (!(await has(process.env.EDGE_CONFIG_SPLIT_ITEM_KEY))) { | ||
| if (!(await has(process.env.GLOBAL_CONFIG_SPLIT_ITEM_KEY))) { |
There was a problem hiding this comment.
Two middlewares call the top-level has()/get() from @vercel/global-config, whose default client reads process.env.EDGE_CONFIG, but the PR renamed the connection-string env var to GLOBAL_CONFIG, so the calls fail at runtime.
Swaps @vercel/edge-config for the renamed @vercel/global-config package and updates user-facing "Edge Config" mentions to "Global Config" in READMEs, comments, and UI copy. Env var names (EDGE_CONFIG), API endpoints, and third-party SDK option keys are left untouched since those haven't been renamed yet.
Speculatively targets @vercel/global-config@1.5.0 (unreleased), renames EDGE_CONFIG* env vars to GLOBAL_CONFIG*, and switches the apple-store REST call to the not-yet-public /v1/global-config endpoint. These examples won't build/deploy until the corresponding platform phases (env var rename, public API route, 1.5.0 release) ship. Note: feature-flag-launchdarkly now fails tsc/next build type checking because @launchdarkly/vercel-server-sdk still depends on the old @vercel/edge-config internally, so its init() rejects a @vercel/global-config client (DeepReadonly<T> structural mismatch). Left as-is per direction; needs a fix once LaunchDarkly's SDK updates its own dependency.
5044a3e to
1830ee7
Compare
1 participant
Summary
@vercel/edge-configfor the renamed@vercel/global-configpackage across all affectedpackage.jsonfiles and lockfiles.from '@vercel/edge-config'→from '@vercel/global-config').edge-middleware/*,flags-sdk/launchdarkly,internal/fields.json,rust/*/AGENTS.md, and the SvelteKit toolbar example.missing-edge-configpages/routes tomissing-global-config(apple-store, split, maintenance-page) and updates their internal redirects/component names.Forward-looking prep (speculative, not yet functional)
At the requester's direction, this also prepares these examples for phases that haven't shipped yet:
@vercel/global-config@1.5.0inpackage.json(not published — lockfiles are intentionally left resolving1.4.3sopnpm installstill works today; bump the lockfiles once1.5.0ships).EDGE_CONFIG/EDGE_CONFIG_ITEM_KEY/EDGE_CONFIG_SPLIT_ITEM_KEY/EDGE_CONFIG_HYPERTUNE_ITEM_KEYenv vars toGLOBAL_CONFIG*(the platform still injectsEDGE_CONFIGtoday per FLA-3175, so these examples won't pick up their connection string until that phase ships)./v1/global-config/{id}/items, which is currently private/undocumented (FLA-3093).edge-config-storesquery param toglobal-config-stores, assuming vercel.com's deploy flow will accept it — unverified.Rebased onto main (#1532)
Rebased onto the LaunchDarkly Marketplace-integration update that landed on
mainin the meantime. That PR already migratedfeature-flag-launchdarklyandflags-sdk/launchdarklyoffEDGE_CONFIGontoEXPERIMENTATION_CONFIG(an unrelated, already-shipped rename tied to the native Marketplace integration, not this Global Config effort) and replaced the deploy button'sintegration-ids/env/edge-config-storesparams with aproducts=Marketplace param. Conflict resolution kept#1532's current structure and dropped this branch's now-obsoleteEDGE_CONFIG→GLOBAL_CONFIG/edge-config-stores→global-config-storesedits for those two examples specifically — they still get the@vercel/global-configpackage swap and "Edge Config" → "Global Config" prose, just not the env-var/deploy-param speculation, since the var isEXPERIMENTATION_CONFIGthere, notEDGE_CONFIG.Known issue:
feature-flag-launchdarklyfailstsc/next buildtype checking —@launchdarkly/vercel-server-sdkstill depends on the old@vercel/edge-configinternally, so itsinit()rejects a@vercel/global-configclient (DeepReadonly<T>structural mismatch). Confirmed still present after the rebase. Left as-is per direction; needs a fix (cast, or pin back to@vercel/edge-config) once LaunchDarkly's SDK updates its own dependency.Intentionally left unchanged:
EmbeddedEdgeConfig/EdgeConfigClienttype names are still exported that way from the SDK (thoughGlobalConfigClientetc. aliases also exist), third-party SDK exports/option keys (EdgeConfigDataAdapter,EdgeConfigWrapper,VercelEdgeConfigInitDataProvider, Ory's ownedgeConfig), and theedge-config.vercel.comconnection-string domain.Linear: FLA-3104
Test plan
tsc --noEmitpasses on all 6 edge-middleware examples when temporarily tested against the real@vercel/global-config@1.4.3release (same API surface as the targeted1.5.0), exceptfeature-flag-launchdarkly(see known issue above, pre-existing from the package rename itself)EDGE_CONFIGmentions outside intentional exceptions (grepsweep)main(Update LaunchDarkly examples for native Vercel Marketplace integration #1532), all conflicts resolved, re-verified type-checking afterward@vercel/global-config@1.5.0, theGLOBAL_CONFIGenv var, and the public/v1/global-configroute actually ship🤖 Generated with Claude Code