Mixed $: statements and runes after Svelte 5 upgrade: update timing drift needs diagnosis

Answer to the Core Question

In Svelte 5 the reactive scheduler has been re‑implemented. All *pure* reactive updates (including $derived and legacy $: blocks that only compute values) are now batched and executed first in a tick. $effect runes are scheduled after those derived updates but still within the same tick. When a parent component’s $: block reads a value that is mutated inside a child’s rune, the mutation is queued for the *next* tick. Consequently the parent’s $: block runs before the child’s rune mutation, producing the observed drift.

Because the ordering is dictated by the scheduler rather than by a documented contract, it is not guaranteed that a legacy $: block will run after a $effect that shares a dependency across a component boundary. The only reliable ordering comes from the new $derived API, which is always evaluated before any $effect in the same tick.

Recommended Migration Strategy

1. Identify all pure derivations that are still written as legacy $: blocks. Migrate them to $derived first. This guarantees they run before any side‑effect logic.
2. Once derivations are stable, convert side‑effect logic to $effect. Because $effect is now scheduled after all derived updates, the relative order will match the legacy behaviour in most cases.
3. For components that must interoperate across a boundary, wrap the shared value in a store or a $derived that the parent can subscribe to. This removes the dependency on the child’s tick.

Minimal Reproduction to Verify Flush Timing

<!-- Parent.svelte -->
<script>
  import Child from './Child.svelte';
  let parentTs;
  $: parentTs = performance.now();
  console.log('Parent $:', parentTs); // runs on each derived update
</script>
<Child on:update={e => console.log('Parent received', e.detail)} />

<!-- Child.svelte -->
<script>
  import { onMount } from 'svelte';
  export let onUpdate;
  let rune = 0;
  // Simulate a rune mutation after mount
  onMount(() => {
    setTimeout(() => {
      rune = 42;
      onUpdate({ detail: performance.now() });
    }, 0);
  });
</script>
<p>{rune}</p>

Run the app and compare performance.now() values logged by the parent’s $: block and the child’s setTimeout. In Svelte 4 the parent’s log will always be after the child’s mutation. In Svelte 5 you will see the parent log earlier, confirming the drift.

Missing Diagnostic Detail

To refine this recommendation, we need to know the exact Svelte 5 compiler build you are using (e.g., beta‑1, RC‑2, or a patched local version) and whether runes are enabled per‑component or globally. These factors influence the scheduler’s batching behaviour and can change the ordering observed.