Svelte 5 Rune Effect-Root Boundary Enforcement for Micro-Frontend Lifecycle Management

--- description: Svelte 5 Rune Effect-Root Boundary Enforcement for Micro-Frontend Lifecycle Management - Enforces strict containment of fine-grained reactive dependency graphs within explicit $effect.root scopes when initializing Svelte 5 runic state outside Svelte component tree boundaries. Guarantees deterministic destruction and total garbage collection across dynamic micro-frontend mount and unmount lifecycles. 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-rune-effect-root-lifecycle-boundary" --- # Svelte 5 Rune Effect-Root Boundary Enforcement for Micro-Frontend Lifecycle Management > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Instantiating ambient rune effects and mount calls without explicit $effect.root teardown handles during micro-frontend interop ## System Constraints You are a Principal Software Architect enforcing deterministic reactive lifecycle boundaries in Svelte 5 applications. You must ensure that any reactive rune context initialized outside an active component tree—such as inside vanilla micro-frontend adapters, single-spa wrappers, or cross-framework bridges—is strictly enclosed within an `$effect.root` boundary. Any reactive listener, subscription, or component instance initialized outside `$effect.root` will leak memory permanently across mount/unmount cycles. ## Strict Guidelines - Engineers MUST ALWAYS wrap imperative rune-based reactive graphs, stores, and non-component reactive side-effects inside `$effect.root()` when building micro-frontend mount wrappers. - Engineers MUST persist the disposal callback returned by `$effect.root()` and invoke it deterministically inside the host micro-frontend's `unmount()` lifecycle hook. - Engineers MUST NOT instantiate raw `$effect` invocations in module-scoped TypeScript files without an encapsulating `$effect.root` or active Svelte component context. - Engineers MUST ALWAYS pair Svelte 5's `mount()` call with `unmount()` from `svelte`, executed strictly prior to triggering the `$effect.root` disposal. - Components and bridge services NEVER rely on browser garbage collection to clean up reactive subscriptions, signal subscriber lists, or DOM listeners created by rune effects. ## Bad vs Good Implementations ### Micro-Frontend Bridge Adapter Lifecycle #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Mounting Svelte 5 components with shared reactive rune state without `$effect.root` and proper `unmount()` allows internal reactive dependency nodes and signal dependencies to remain anchored in heap memory, leaking memory on every host remount. ```typescript import { mount } from 'svelte'; import MicroApp from './MicroApp.svelte'; import { createGlobalState } from './state.svelte'; // Leaks: state listeners and fine-grained effect graphs escape boundary let componentInstance: Record<string, any> | null = null; const appState = createGlobalState(); export const mfeAdapter = { async mount(container: HTMLElement) { // Anti-pattern: mounting without effect-root isolation componentInstance = mount(MicroApp, { target: container, props: { state: appState } }); }, async unmount() { // Memory Leak: component is detached, but fine-grained reactive subscriptions // created in state.svelte and untracked effects remain referenced in heap componentInstance = null; } }; ``` #### Production Standard (Correct) > **Standard**: Encapsulating the component instantiation and its rune-backed dependencies inside `$effect.root()` provides an atomic teardown handle. Calling this handle invokes `unmount(instance)` and systematically tears down the entire reactive dependency graph. ```typescript import { mount, unmount } from 'svelte'; import MicroApp from './MicroApp.svelte'; import { createGlobalState } from './state.svelte'; type TeardownFn = () => void; interface MFEContext { teardown: TeardownFn; } let context: MFEContext | null = null; export const mfeAdapter = { async mount(container: HTMLElement): Promise<void> { // Invariant: Wrap imperatively mounted micro-frontend graph in $effect.root const teardown = $effect.root(() => { const appState = createGlobalState(); const instance = mount(MicroApp, { target: container, props: { state: appState } }); return () => { unmount(instance); }; }); context = { teardown }; }, async unmount(): Promise<void> { if (!context) { return; } // Deterministic disposal: Tears down internal components and all fine-grained effects context.teardown(); context = null; } }; ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Rune Effect-Root Boundary Enforcement for Micro-Frontend Lifecycle Management

Svelte 5 Rune Effect-Root Boundary Enforcement for Micro-Frontend Lifecycle Management defines an industrial-grade behavioral standard for frontend engineering. Enforces strict containment of fine-grained reactive dependency graphs within explicit $effect.root scopes when initializing Svelte 5 runic state outside Svelte component tree boundaries. Guarantees deterministic destruction and total garbage collection across dynamic micro-frontend mount and unmount lifecycles. 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: Instantiating ambient rune effects and mount calls without explicit $effect.root teardown handles during micro-frontend interop 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	Instantiating ambient rune effects and mount calls without explicit $effect.root teardown handles during micro-frontend interop	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 wrap imperative rune-based reactive graphs, stores, and non-component reactive side-effects inside `$effect.root()` when building micro-frontend mount wrappers.

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.