studio-config-option-lifecycle

Name: studio-config-option-lifecycle
Author: remotion-dev

54kstars3.9kforks

How to install studio-config-option-lifecycle?

remotion-dev/remotion/studio-config-option-lifecycle

$npx -y skills add remotion-dev/remotion --skill studio-config-option-lifecycle

Installs into the current project.

Summary

Classify and wire Remotion Studio config options as either startup-fixed or reloadable while preventing mixed lifecycle behavior across consumers. Use when adding, changing, or reviewing a Config setter or CLI option consumed by Studio, its preview server, compiler, HTML bootstra

Files · 1

View on GitHub

SKILL.md

1	# Studio Config Option Lifecycle
2
3	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.
4
5	## Classify the whole option
6
7	Inspect every Studio consumer, then assign one lifecycle to the whole option:
8
9	- Startup-fixed: Changing the value requires recreating a server, compiler, watcher, directory mapping, or other initialized resource.
10	- Reloadable: Every Studio consumer can safely use the new value after the browser reload or at another deliberate request boundary.
11
12	If any consumer must be startup-fixed, make the option startup-fixed for all Studio consumers. Do not implement mixed lifecycle behavior.
13
14	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.
15
16	## Wire startup-fixed values
17
18	Resolve the option once in `packages/cli/src/studio.ts` before calling `startStudio()`:
19
20	```ts
21	const fixedValue = option.getValue({commandLine: parsedCli}).value;
22
23	await StudioServerInternals.startStudio({
24	fixedValue,
25	});
26	```
27
28	Pass the value, not a getter, through `startStudio()`, `startServer()`, and the consumer. Keep new internal parameters required; use `T \| null` when absence is valid.
29
30	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.
31
32	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.
33
34	## Wire reloadable values
35
36	Read reloadable options through a getter that retains CLI precedence:
37
38	```ts
39	const getValue = () =>
40	option.getValue({commandLine: parsedCli}).value;
41
42	await StudioServerInternals.startStudio({
43	getValue,
44	});
45	```
46
47	Pass the getter as a required internal callback and invoke it only at the boundary that should observe config changes, such as generating Studio HTML after the `config-file-changed` browser reload. Do not evaluate the getter earlier and pass its result onward.
48
49	Use the existing `getStudioRuntimeConfig()` path for values already represented by `StudioRuntimeConfig`. Be careful when extending that exported type: adding a required property can be a public API break. For independent HTML bootstrap values, pass a dedicated getter through the internal Studio server layers.
50
51	Only use this pattern when all Studio consumers are reloadable. Typical examples include UI behavior and HTML bootstrap defaults that do not require rebuilding initialized resources.
52
53	## Resolve lifecycle conflicts
54
55	Search all reads of the option and decide each one independently:
56
57	```sh
58	rg -n "myOption\|setMyOption\|my-cli-flag" packages
59	```
60
61	If the consumers do not all support reloading, capture the option once at Studio startup and pass that same value to every consumer. For example, if the active preview compiler cannot change bundlers, future render jobs must retain the startup bundler choice as well.
62
63	Treat aliases as one option. If a deprecated setter updates multiple underlying values, make every affected Studio consumer follow the stricter startup-fixed lifecycle.
64
65	## Reset and rollback
66
67	Ensure config reload resets the option before executing the changed file, so deleting a setter restores the default. Options registered through `BrowserSafeApis.options` and exposed directly through `Config` are reset by `resetBrowserSafeConfigOptions()`. Add an explicit reset in `ConfigInternals.resetConfigOptions()` for custom module state.
68
69	Preserve transactional reload behavior: an invalid changed config must leave the previous valid configuration active.
70
71	## Test the lifecycle
72
73	Add tests that prove the classification:
74
75	- Reloadable: change the option after the initial read, cross the intended reload/request boundary, and assert the new value is observed.
76	- Startup-fixed: capture the initial value, change config state, and assert the initialized consumer still receives the original value.
77	- Cross-consumer: assert every Studio consumer receives the same startup snapshot when any one consumer requires it.
78	- Reset: omit a previously set option on reload and assert its default is restored.
79	- Nullable internal inputs: pass `null` explicitly in fixtures and call sites.
80
81	Run focused builds and checks for the affected packages:
82
83	```sh
84	bunx turbo run make lint form

People who liked this also viewed

6 picks

Type

studio-config-option-lifecycle

54kstars3.9kforks

View on GitHub

How to install studio-config-option-lifecycle?

remotion-dev/remotion/studio-config-option-lifecycle

$npx -y skills add remotion-dev/remotion --skill studio-config-option-lifecycle

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Studio Config Option Lifecycle
2
3	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.
4
5	## Classify the whole option
6
7	Inspect every Studio consumer, then assign one lifecycle to the whole option:
8
9	- Startup-fixed: Changing the value requires recreating a server, compiler, watcher, directory mapping, or other initialized resource.
10	- Reloadable: Every Studio consumer can safely use the new value after the browser reload or at another deliberate request boundary.
11
12	If any consumer must be startup-fixed, make the option startup-fixed for all Studio consumers. Do not implement mixed lifecycle behavior.
13
14	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.
15
16	## Wire startup-fixed values
17
18	Resolve the option once in `packages/cli/src/studio.ts` before calling `startStudio()`:
19
20	```ts
21	const fixedValue = option.getValue({commandLine: parsedCli}).value;
22
23	await StudioServerInternals.startStudio({
24	fixedValue,
25	});
26	```
27
28	Pass the value, not a getter, through `startStudio()`, `startServer()`, and the consumer. Keep new internal parameters required; use `T \| null` when absence is valid.
29
30	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.
31
32	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.
33
34	## Wire reloadable values
35
36	Read reloadable options through a getter that retains CLI precedence:
37
38	```ts
39	const getValue = () =>
40	option.getValue({commandLine: parsedCli}).value;
41
42	await StudioServerInternals.startStudio({
43	getValue,
44	});
45	```
46
47	Pass the getter as a required internal callback and invoke it only at the boundary that should observe config changes, such as generating Studio HTML after the `config-file-changed` browser reload. Do not evaluate the getter earlier and pass its result onward.
48
49	Use the existing `getStudioRuntimeConfig()` path for values already represented by `StudioRuntimeConfig`. Be careful when extending that exported type: adding a required property can be a public API break. For independent HTML bootstrap values, pass a dedicated getter through the internal Studio server layers.
50
51	Only use this pattern when all Studio consumers are reloadable. Typical examples include UI behavior and HTML bootstrap defaults that do not require rebuilding initialized resources.
52
53	## Resolve lifecycle conflicts
54
55	Search all reads of the option and decide each one independently:
56
57	```sh
58	rg -n "myOption\|setMyOption\|my-cli-flag" packages
59	```
60
61	If the consumers do not all support reloading, capture the option once at Studio startup and pass that same value to every consumer. For example, if the active preview compiler cannot change bundlers, future render jobs must retain the startup bundler choice as well.
62
63	Treat aliases as one option. If a deprecated setter updates multiple underlying values, make every affected Studio consumer follow the stricter startup-fixed lifecycle.
64
65	## Reset and rollback
66
67	Ensure config reload resets the option before executing the changed file, so deleting a setter restores the default. Options registered through `BrowserSafeApis.options` and exposed directly through `Config` are reset by `resetBrowserSafeConfigOptions()`. Add an explicit reset in `ConfigInternals.resetConfigOptions()` for custom module state.
68
69	Preserve transactional reload behavior: an invalid changed config must leave the previous valid configuration active.
70
71	## Test the lifecycle
72
73	Add tests that prove the classification:
74
75	- Reloadable: change the option after the initial read, cross the intended reload/request boundary, and assert the new value is observed.
76	- Startup-fixed: capture the initial value, change config state, and assert the initialized consumer still receives the original value.
77	- Cross-consumer: assert every Studio consumer receives the same startup snapshot when any one consumer requires it.
78	- Reset: omit a previously set option on reload and assert its default is restored.
79	- Nullable internal inputs: pass `null` explicitly in fixtures and call sites.
80
81	Run focused builds and checks for the affected packages:
82
83	```sh
84	bunx turbo run make lint form

People who liked this also viewed

6 picks

Type