memory-leak-audit

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

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Event listeners and disposable objects that are never released cause memory leaks that grow with usage, degrading editor performance over time. This Skill provides a systematic checklist to detect and fix the most common leak patterns 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. - Pattern Library with Fixes: Each check includes bad/good TypeScript examples using addDisposableListener, Event.once, MutableDisposable, DisposableStore, and onWillDispose. - Real-World Validation: Every rule is backed by a merged PR reference (e.g., PR #283466, #290505) showing the actual leak it fixed. - Use Case: A terminal find widget leaks one listener per search. Run the audit to identify the repeated-method-call pattern, replace this._register() with a MutableDisposable, and verify with ensureNoDisposablesAreLeakedInTestSuite(). ## Quick Start Review this file for memory leaks using the memory leak audit checklist and report any listeners or disposables that are not properly cleaned up.

Frequently Asked Questions about memory-leak-audit

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

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

Audit each listener registration against a checklist: DOM events must use addDisposableListener, one-time events must use Event.once, and listeners created in repeated methods must use MutableDisposable instead of this._register. Verify fixes with ensureNoDisposablesAreLeakedInTestSuite in tests.

How to fix listeners leaking when a method is called repeatedly?▼

Replace this._register() inside the method with a class-level MutableDisposable field, then assign the new listener to its value property. This guarantees at most one active listener regardless of how many times the method runs.

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

Use Event.once for events that should fire only once, such as lifecycle, close, or first-change events. It automatically removes the listener after the first invocation, preventing permanent registrations that outlive their purpose.

Why do DisposableStores tied to a model still leak?▼

They leak when nothing disposes the store after the model dies. Register model.onWillDispose(() => store.dispose()) inside the store itself so cleanup is automatic when the model is destroyed.

How do I verify a memory leak fix actually worked?▼

Add ensureNoDisposablesAreLeakedInTestSuite() to the test suite, compare listener counts before and after repeated operations, and confirm object counts stabilize instead of growing linearly with usage.