vibecheck0.3.0
Performancememory-leakerror

JavaScript memory leak in Svelte

A memory leak means the heap grows every time you navigate or interact and never comes back down, until long sessions jank, stutter, and eventually crash the tab. It is one of the hardest bugs to catch in review because it only shows up over time — the happy-path click looks fine. AI-generated effects and subscriptions are a frequent source: the setup is written, the cleanup is forgotten.

Framework fixes
GeneralReactNext.jsVueSvelteVanilla JS

Symptoms

  • The page gets slower the longer it stays open
  • Heap usage climbs across route changes and never recovers after GC
  • Eventually a tab crash or "Aw, Snap" on long sessions
  • DevTools Memory timeline shows a rising staircase of retained objects

How VibeCheck catches it

In your widget · Problems

errormemory-leakPotential memory leak (27% growth)

To your coding agent · MCP

agent › get_detected_issues
→ { detector: "memory-leak", issue: "Potential memory leak (27% growth)", threshold: "> 10% heap growth over 30s without GC recovery (warning), > 25% (error)" }

The same string in your widget and in your agent’s context — no screenshot, no copy-paste.

Root causes

  • addEventListener / setInterval / setTimeout without a matching cleanup
  • Subscriptions (WebSocket, SSE, store, RxJS) never unsubscribed on unmount
  • State that only grows — arrays/maps/caches that append and never evict
  • Detached DOM nodes still referenced by a closure or long-lived variable

The fix for Svelte

In Svelte 5, return a cleanup from $effect; in Svelte 4 use onDestroy. Either releases the resource when the component is torn down.

svelte
<script lang="ts">
  $effect(() => {
    const id = setInterval(tick, 1000)
    const onResize = () => (w = window.innerWidth)
    window.addEventListener('resize', onResize)
    return () => {
      clearInterval(id)
      window.removeEventListener('resize', onResize)
    }
  })
</script>

Svelte docs →

Steps

  1. Audit every effect/lifecycle hook that adds a listener, timer, or subscription
  2. Return or register a cleanup that removes exactly what was added
  3. Bound caches and growing arrays with an eviction policy (e.g. LRU or max size)

See the general, framework-agnostic fix →

FAQ

How do I confirm it is really a leak and not normal growth?
Take heap snapshots in DevTools Memory before and after repeating an action (e.g. navigate away and back a few times). If retained size keeps climbing and never drops after GC, it’s a leak. VibeCheck watches for exactly this: sustained growth with no recovery.
React Strict Mode runs my effect twice — is that a leak?
No, that is intentional in development to surface missing cleanup. If your cleanup is correct and idempotent, the double-invoke is harmless and doesn’t happen in production.
What are detached DOM nodes?
Nodes removed from the document but still referenced by JavaScript (a closure, a cached array, an event handler). They can’t be garbage-collected. Drop the reference when you remove the node.