Studio Config Option Lifecycle

Studio Config Option Lifecycle

Make reload behavior explicit for every Studio-facing option. A config file is reset and re-executed when it changes, but a consumer only observes the new value if its code reads the option again.

Classify the whole option

Inspect every Studio consumer, then assign one lifecycle to the whole option:

• Startup-fixed: Changing the value requires recreating a server, compiler, watcher, directory mapping, or other initialized resource.
• Reloadable: Every Studio consumer can safely use the new value after the browser reload or at another deliberate request boundary.

If any consumer must be startup-fixed, make the option startup-fixed for all Studio consumers. Do not implement mixed lifecycle behavior.

Do not infer reloadability from Config.set*() state being updated. Config re-execution updates module state regardless of whether an already-created consumer observes it.

Wire startup-fixed values

Resolve the option once in packages/cli/src/studio.ts before calling startStudio():

const fixedValue = option.getValue({commandLine: parsedCli}).value;

await StudioServerInternals.startStudio({
	fixedValue,
});

Pass the value, not a getter, through startStudio(), startServer(), and the consumer. Keep new internal parameters required; use T | null when absence is valid.

Capture startup-fixed render settings in StudioRenderJobFixedConfig at the Studio queue boundary and thread that object into the job processor. Do not call option.getValue() from the processor, because config state may have changed since Studio startup.

Typical startup-fixed consumers include the Studio port, entry point, active compiler choice and override, polling mode, public directory and watcher, network binding, and cross-site-isolation headers.

Wire reloadable values

Read reloadable options through a getter that retains CLI precedence:

const getValue = () =>
	option.getValue({commandLine: parsedCli}).value;