memory-leak-audit

Audit TypeScript code for memory leaks in event listeners and disposable patterns.

Updated Sep 3, 2026
One-click install
npx skills add https://github.com/az0512124155azz-sys/CodeForge --skill memory-leak-audit-az0512124155azz-sys
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: memory-leak-audit
Source: https://github.com/az0512124155azz-sys/CodeForge/tree/main/.github/skills/memory-leak-audit
Command: npx skills add https://github.com/az0512124155azz-sys/CodeForge --skill memory-leak-audit-az0512124155azz-sys

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Event listeners and disposable objects that are never released cause memory leaks where listener counts and heap usage grow with every user action. This Skill provides a systematic checklist to find and fix these leaks in VS Code-style TypeScript codebases. ## Core Features & Use Cases - Six-Step Audit Checklist: Covers DOM event listeners, one-time events, repeated method calls, model-tied DisposableStores, resource pools, and test validation. - Concrete Fix Patterns: Shows bad and good code for addDisposableListener, Event.once, MutableDisposable, DisposableStore, and onWillDispose usage. - Use Case: A widget leaks listeners every time it toggles. Walk the checklist to find the raw .onload assignment, replace it with addDisposableListener() registered via this._register(), and confirm the fix with ensureNoDisposablesAreLeakedInTestSuite(). ## Quick Start Audit this file for memory leaks and fix any event listener or disposable patterns that violate the checklist.

Frequently Asked Questions about memory-leak-audit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix memory leaks from event listeners in TypeScript?▼

Replace raw addEventListener or .onclick assignments with addDisposableListener() and register the result via this._register(). For one-time lifecycle events, wrap the event with Event.once() so the listener removes itself after the first invocation.

How to prevent listener leaks in methods called multiple times?▼

Do not call this._register() inside methods that run repeatedly, since each call adds another listener to the class store. Instead use a MutableDisposable field and assign the new listener to its .value, which disposes the previous one automatically.

When should I use Event.once instead of a regular event subscription?▼

Use Event.once for events that should fire only once, such as disposal, close, or first-change notifications. A regular subscription stays registered forever after firing, leaking the listener and its captured references.

How do I verify a memory leak fix in tests?▼

Call ensureNoDisposablesAreLeakedInTestSuite() at the top of the test suite so leaked disposables fail the test automatically. You can also compare listener counts before and after repeated operations to confirm counts stay stable.

Why do DisposableStores tied to a model still leak?▼

A DisposableStore leaks if nothing disposes it when its model goes away. Register model.onWillDispose(() => store.dispose()) inside the store itself so the store cleans up all its subscriptions when the model lifecycle ends.