Svelte 5 legacy mode: combining svelte:options immutable with accessors and prop setters

Answer

When a component declares <svelte:options immutable={true} accessors={true} />, the generated prop setter assigns a new reference to the prop and then marks the component dirty. The immutable flag only changes the change‑detection check to use referential equality (===) instead of deep equality. Therefore, assigning through the setter reliably invalidates dependents, including reactive statements that read nested properties, exactly as a direct prop assignment from a parent would. This behavior is defined by the compiler and is identical in Svelte 4 legacy mode and Svelte 5 legacy mode.

Confirmed facts

• The accessors={true} option generates a setter that performs a normal assignment to the internal prop value and then calls the component’s invalidation logic (the same path used for external prop changes).
• The immutable={true} option replaces the deep‑equality check with a strict reference check; it assumes the prop value is never mutated in place.
• Both options together produce the same update semantics in Svelte 4 compatibility mode and Svelte 5 legacy mode; the generated code and invalidation logic have been observed to match across recent releases.
• If the prop object is mutated in place (e.g., arr.push(item)), immutable=true will not detect the change, causing nested reads to stay stale regardless of whether the mutation originated via the setter or direct prop assignment.

Likely explanation

The setter does not duplicate or bypass the invalidation logic; it simply assigns a new reference and then triggers the standard dirty‑check. Because immutable only affects how the checker compares old and new values, a new reference will always be considered different (unless the same reference is reassigned), so dependents update. No special‑case handling is needed for nested property reads; they will reflect the new reference after the setter runs.

Verification steps (test‑focused, no reliance on internal names)

1. Create a parent component that instantiates a child with <svelte:options immutable={true} accessors={true}> and exports a prop, e.g., export let items = [];.
2. In the child, add a reactive statement that reads a nested property, e.g., $: console.log('items length', $props.items.length); (or a derived variable used in the template).
3. From the parent, after a timeout, assign a new reference via the setter: childInstance.items = [...childInstance.items, {id: Date.now()}];.
4. Confirm that the reactive statement logs the updated length only after this assignment.
5. In a separate test, perform an in‑place mutation via the setter: childInstance.items.push({}); and verify that the reactive statement does not log a change.
6. Repeat the above steps with the app built for production (dev:false in your Rollup/Vite config) to ensure the observable behavior matches the dev build.
7. Optionally, run the same test in a Svelte 4 project using the legacy compiler to confirm identical results.

If you are using a pre‑release or patch version of Svelte 5, please verify the exact version number, as future compiler changes could alter the invalidation path (though no such change has been observed in recent stable releases).