memory-leak-audit

Audit TypeScript code for memory leaks and disposable lifecycle issues.

1|Updated Aug 27, 2026
One-click install
npx skills add https://github.com/Niiihuel/openide --skill memory-leak-audit-niiihuel
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: memory-leak-audit
Source: https://github.com/Niiihuel/openide/tree/main/vscode/.github/skills/memory-leak-audit
Command: npx skills add https://github.com/Niiihuel/openide --skill memory-leak-audit-niiihuel

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Event listeners, DOM handlers, and disposables that are never released cause listener counts and heap usage to grow over time, producing the most common bug category in VS Code-style codebases. This Skill provides a systematic checklist to find and fix those leaks. ## 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 versus good code for addDisposableListener, Event.once, MutableDisposable, DisposableStore, and onWillDispose. - Use Case: When a terminal find widget leaks one listener per search, apply the MutableDisposable pattern so repeated startSearch() calls keep at most one active listener. ## Quick Start Review this file for memory leaks and disposable lifecycle issues using the memory leak audit 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 repeatedly?▼

Use a MutableDisposable field registered once on the class, then assign the new listener to its .value inside the method. This guarantees at most one active listener no matter how many times the method runs, unlike calling this._register on every invocation.

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, which leaks 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 tests automatically. You can also compare listener counts before and after repeated operations to confirm counts stabilize.

Why do pooled objects like lists and trees leak disposables?▼

Leak occurs when item listeners are registered to the pool class with this._register, so they are never cleaned per item. Create an item-scoped DisposableStore and return an object whose dispose method disposes that store.