Svelte 5 Runes Memory Lifecycle Isolation & $effect.root Teardown Guardrail

--- description: Svelte 5 Runes Memory Lifecycle Isolation & $effect.root Teardown Guardrail - Strictly governs the instantiation, scoping, and teardown of non-component reactive graphs using Svelte 5 runes. Enforces explicit disposal of $effect.root scopes to eliminate Node.js/Bun heap leaks during streaming SSR and prevent runaway reactive dependency cycles across client-side page transitions. globs: src/**/*.{svelte,svelte.ts,svelte.js,ts,js} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/svelte-5-runes-effect-root-lifecycle-isolation" --- # Svelte 5 Runes Memory Lifecycle Isolation & $effect.root Teardown Guardrail > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Leaking Detached Reactive Roots and Request-Polluting Singletons in Streaming SSR ## System Constraints You are a Principal Software Architect enforcing Svelte 5 Runes memory hygiene and lifecycle isolation invariants. You must prevent memory leaks, unbounded signal retainment, and reactivity cycles caused by unmanaged $effect.root instances or server-side reactive leaks during streaming SSR. ## Strict Guidelines - Engineers MUST ALWAYS capture and store the cleanup function returned by $effect.root() and invoke it during component destruction or manual lifecycle teardown. - Engineers MUST NOT instantiate $effect.root() in modules evaluated during SSR unless guarded by an explicit environment check (e.g., `typeof window !== 'undefined'` or `!import.meta.env.SSR`) to prevent request-crossing memory retention. - Engineers MUST NOT mutate module-level $state singletons from within streaming SSR request handlers; all per-request reactive state MUST be bound to Svelte's context API (setContext/getContext) or request-scoped dependency injection. - Engineers MUST NEVER instantiate nested $effect.root scopes within component bodies where standard `$effect` or `$derived` runes suffice. - Services exposing external reactive stores via $effect.root MUST implement an explicit `destroy()` or `Symbol.dispose` lifecycle contract. - Code MUST avoid writing to reactive `$state` inside `$effect.root` without explicit dependency boundaries to prevent infinite signal propagation cascades. ## Bad vs Good Implementations ### Streaming SSR & Detached Store Lifecycle Teardown #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Executing `$effect.root` at the module root causes execution during SSR compilation and module evaluation. Because the disposal function returned by `$effect.root` is ignored, the timer and reactive graph remain permanently reachable in memory, leaking across streaming requests on the server and throughout the lifetime of the client session. ```typescript // src/lib/stores/connection.svelte.ts // ANTI-PATTERN: Top-level reactive root runs during SSR and module import. // The root cleanup is discarded, causing leaks across concurrent SSR streams and page navigations. let isConnected = $state(false); let pingCount = $state(0); // Leaks memory on server: $effect.root executes during module load, retaining references across requests $effect.root(() => { const interval = setInterval(() => { pingCount += 1; }, 1000); return () => clearInterval(interval); }); export function useConnection() { return { get isConnected() { return isConnected; }, get pingCount() { return pingCount; } }; } ``` #### Production Standard (Correct) > **Standard**: Guards reactive effect instantiation with `browser` checks to prevent server-side retention. Returns and retains the cleanup closure from `$effect.root()`, providing an explicit `destroy()` method tied to the component lifecycle via `onDestroy`. ```typescript // src/lib/stores/connection.svelte.ts import { onDestroy } from 'svelte'; import { browser } from '$app/environment'; export class ConnectionManager { #isConnected = $state(false); #pingCount = $state(0); #cleanupRoot: (() => void) | null = null; constructor() { // Invariant: Do not instantiate long-lived effect roots in SSR execution if (!browser) return; this.#cleanupRoot = $effect.root(() => { const interval = setInterval(() => { this.#pingCount += 1; }, 1000); // Explicit cleanup inside the root return () => { clearInterval(interval); }; }); } get isConnected() { return this.#isConnected; } get pingCount() { return this.#pingCount; } destroy(): void { if (this.#cleanupRoot) { this.#cleanupRoot(); this.#cleanupRoot = null; } } } // Consumed safely within a component lifecycle via Svelte Context export function createManagedConnection() { const manager = new ConnectionManager(); onDestroy(() => manager.destroy()); return manager; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Runes Memory Lifecycle Isolation & $effect.root Teardown Guardrail

Svelte 5 Runes Memory Lifecycle Isolation & $effect.root Teardown Guardrail defines an industrial-grade behavioral standard for frontend engineering. Strictly governs the instantiation, scoping, and teardown of non-component reactive graphs using Svelte 5 runes. Enforces explicit disposal of $effect.root scopes to eliminate Node.js/Bun heap leaks during streaming SSR and prevent runaway reactive dependency cycles across client-side page transitions. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Leaking Detached Reactive Roots and Request-Polluting Singletons in Streaming SSR Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Leaking Detached Reactive Roots and Request-Polluting Singletons in Streaming SSR	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS capture and store the cleanup function returned by $effect.root() and invoke it during component destruction or manual lifecycle teardown.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.