Svelte 5 $effect.root Deterministic Teardown Boundary in Micro-Frontend Shells

--- description: Svelte 5 $effect.root Deterministic Teardown Boundary in Micro-Frontend Shells - Enforces strict capture, storage, and deterministic invocation of the disposal function returned by $effect.root when creating reactive rune scopes outside the standard Svelte component tree. Prevents detached signal subgraphs, leaked runtime subscriptions, and cross-application memory growth inside long-lived single-page micro-frontend host containers. globs: src/**/*.{ts,js,svelte} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/svelte-5-effect-root-teardown-boundary" --- # Svelte 5 $effect.root Deterministic Teardown Boundary in Micro-Frontend Shells > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Discarding $effect.root Disposal Handles During Micro-Frontend Mounting and Service Instantiation ## System Constraints You are a Principal Software Architect enforcing deterministic reactive boundaries in Svelte 5. Runes like $effect cannot exist outside component boundaries without explicit root encapsulation. When using $effect.root to establish reactive scopes in framework-agnostic controllers, vanilla TS adapters, or micro-frontend mounting wrappers, the returned cleanup function MUST be stored and invoked during unmount. Never discard an $effect.root cleanup handle. Never rely on host garbage collection to tear down active runes graphs. ## Strict Guidelines - Engineers MUST ALWAYS capture the teardown callback returned by `$effect.root` and register it with the micro-frontend unmount lifecycle contract or AbortSignal. - Engineers MUST NOT invoke `$effect.root` within an existing Svelte 5 component lifecycle where native `$effect` with automatic cleanup is already supported. - Code MUST explicitly decouple DOM event listeners, third-party observer subscriptions, and timer handles inside the `$effect.root` internal teardown function or pass them through its inner return function. - Services MUST implement an idempotent `dispose()` or `destroy()` method that executes the stored `$effect.root` teardown handle exactly once. - Components and adapters NEVER allow mount functions to resolve without returning or registering a formal unmount hook that invokes the root teardown handle. ## Bad vs Good Implementations ### Micro-Frontend Shell Lifecycle Adapter with $effect.root #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Ignoring the return value of `$effect.root` leaves reactive dependencies and inner `$effect` instances active indefinitely in the host application. Over repeated micro-frontend mount and unmount cycles, orphaned reactive graphs accumulate in memory, causing severe resource leaks and zombie event executions. ```typescript import { mount, unmount } from 'svelte'; import MicroFrontendApp from './MicroFrontendApp.svelte'; import { createSyncStore } from './syncStore.svelte'; interface MountOptions { target: HTMLElement; props: Record<string, unknown>; } export function mountMicroFrontend(container: HTMLElement, options: MountOptions) { const syncStore = createSyncStore(); // CRITICAL BUG: $effect.root teardown callback is ignored and orphaned. // Signals created inside createSyncStore or effect blocks will never be detached. $effect.root(() => { $effect(() => { console.log('Synchronizing host context:', syncStore.data); }); }); const instance = mount(MicroFrontendApp, { target: container, props: options.props }); return { destroy() { // Only unmounts the component tree; the effect.root remains alive in host memory unmount(instance); } }; } ``` #### Production Standard (Correct) > **Standard**: The cleanup function returned by `$effect.root` is explicitly captured and executed idempotently inside the `destroy()` teardown contract alongside `unmount(appInstance)`. This guarantees complete de-registration of reactive listeners, timers, and dependencies from the host environment. ```typescript import { mount, unmount } from 'svelte'; import MicroFrontendApp from './MicroFrontendApp.svelte'; import { createSyncStore } from './syncStore.svelte'; interface MountOptions { target: HTMLElement; props: Record<string, unknown>; } export interface MicroFrontendInstance { destroy(): void; } export function mountMicroFrontend(container: HTMLElement, options: MountOptions): MicroFrontendInstance { let isDestroyed = false; const syncStore = createSyncStore(); // INVARIANT: Explicitly capture the root cleanup callback const cleanupRoot = $effect.root(() => { $effect(() => { console.log('Synchronizing host context:', syncStore.data); }); return () => { syncStore.dispose(); }; }); const appInstance = mount(MicroFrontendApp, { target: container, props: options.props }); return { destroy() { if (isDestroyed) return; isDestroyed = true; // Deterministically tear down the Svelte 5 component tree first unmount(appInstance); // Explicitly tear down the out-of-tree reactive signal boundary cleanupRoot(); } }; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 $effect.root Deterministic Teardown Boundary in Micro-Frontend Shells

Svelte 5 $effect.root Deterministic Teardown Boundary in Micro-Frontend Shells defines an industrial-grade behavioral standard for frontend engineering. Enforces strict capture, storage, and deterministic invocation of the disposal function returned by $effect.root when creating reactive rune scopes outside the standard Svelte component tree. Prevents detached signal subgraphs, leaked runtime subscriptions, and cross-application memory growth inside long-lived single-page micro-frontend host containers. 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: Discarding $effect.root Disposal Handles During Micro-Frontend Mounting and Service Instantiation 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	Discarding $effect.root Disposal Handles During Micro-Frontend Mounting and Service Instantiation	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 the teardown callback returned by `$effect.root` and register it with the micro-frontend unmount lifecycle contract or AbortSignal.

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.