VSF2 replaces VSF1 static config with split middleware.config.js and public runtimeConfig

Question

A team is porting a multi-store VSF1 theme to VSF2 and must decide where each former config/default.json key belongs now that configuration is split between server middleware and public runtime config. In VSF1, one static tree was visible to both server and client and fixed at build time. VSF2 instead reads server-only values from middleware.config.js and browser-needed values from Nuxt runtimeConfig.public through useConfig.

The compatibility boundary is one-way and there is no automated migration for this split. Teams must classify every legacy setting—storeCode, currency, tax, cart settings—as either secret-server or public-runtime. Multi-store storeViews complicate the decision because the same logical value may need to exist in per-integration middleware settings and in public runtime config simultaneously. Nuxt version sensitivity adds further uncertainty, since runtimeConfig resolution differs across Nuxt 2/3 and VSF2 point releases.

For a multi-store VSF1 project, how should each legacy key be classified between middleware.config.js and runtimeConfig.public? Where should storeCode and storeViews live so SSR and hydration agree without leaking server credentials into the client bundle? How can the per-key mapping be validated against the exact pinned Nuxt and VSF2 versions before cutover?

Tasadduq Burney · Answer

Configuration Classification Strategy
To migrate from a VSF1 config/default.json to VSF2, you must apply a least-privilege model. If a value is not explicitly required by a Vue component or browser-side JavaScript, it must remain on the server.

Key Mapping Guide

Legacy Key Type
      VSF2 Destination
      Reasoning

API Secrets, Private Tokens
      middleware.config.js
      Prevents leakage into client-side bundles.

Currency, Tax Settings, Public IDs
      runtimeConfig.public
      Required for UI rendering and client-side state.

storeCode / storeViews
      Both
      Middleware needs them for API routing; Client needs them for hydration/context.

Handling Multi-Store storeViews
To ensure SSR and hydration agree without leaking credentials, storeCode and storeViews must be duplicated across both configuration layers. The server uses the middleware config to determine which backend integration to hit, while the client uses the public runtime config to maintain state consistency during hydration.
Assumption: It is assumed that these values are populated via environment variables at runtime rather than hard-coded, allowing the same build to serve multiple store views.

Validation and Verification
Because Nuxt versioning (2 vs 3) changes how runtimeConfig is resolved, you must validate the mapping against your specific pinned version before cutover:

Bundle Audit: Run a production build and grep the resulting client-side JS bundles for any keys that should be exclusive to middleware.config.js.
  Network Inspection: Check the browser's Network tab during the initial page load. Ensure the payload containing the public config does not include server-side secrets.
  State Verification: Use Vue DevTools to confirm that the object returned by useConfig() matches the expected storeView for the current request.

Diagnostic Requirement: Please specify the exact Nuxt version (e.g., 2.15.x or 3.x) and VSF2 point release, as the syntax for accessing runtimeConfig differs significantly between these versions.

VSF2 replaces VSF1 static config with split middleware.config.js and public runtimeConfig

1 answer

Configuration Classification Strategy

Key Mapping Guide

Handling Multi-Store storeViews

Validation and Verification

Your perspective belongs here.

0 question comments

Legacy Key Type	VSF2 Destination	Reasoning
API Secrets, Private Tokens	`middleware.config.js`	Prevents leakage into client-side bundles.
Currency, Tax Settings, Public IDs	`runtimeConfig.public`	Required for UI rendering and client-side state.
`storeCode` / `storeViews`	Both	Middleware needs them for API routing; Client needs them for hydration/context.