
Memory Leak Audit
Audit TypeScript/UI code for disposable and event-listener leaks using VS Code’s addDisposableListener, Event.once, and DisposableStore patterns.
Overview
Memory Leak Audit is an agent skill most often used in Ship (also Build frontend) that audits event listeners and disposables to prevent listener-count growth and lifecycle leaks.
Install
npx skills add https://github.com/microsoft/vscode --skill memory-leak-auditWhat is this skill?
- Ordered audit checklist for DOM listeners, one-time events, and repeated setup paths
- Enforces addDisposableListener instead of raw onload, onclick, or addEventListener
- Covers Event.once, MutableDisposable, DisposableStore, and onWillDispose lifecycle hooks
- References real VS Code leak fixes (e.g. extension icon widget listener growth)
- Targets constructors and methods called repeatedly that accumulate subscriptions
- PR #280566: extension icon widget leaked 185 listeners after 37 toggles
Adoption & trust: 1.4k installs on skills.sh; 186k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your UI or extension leaks objects because listeners and handlers are registered repeatedly without a disposable cleanup path.
Who is it for?
Extension and desktop-app authors fixing leak reports or reviewing any code that subscribes to DOM, model, or emitter events in TypeScript.
Skip if: Pure backend services with no long-lived UI, or teams that do not use disposable-oriented patterns in their codebase.
When should I use this skill?
Reviewing event listeners, DOM handlers, lifecycle callbacks, fixing leak reports, or working with onWillDispose/onDidClose and disposable stores.
What do I get? / Deliverables
Reviewed code follows VS Code disposable conventions so listeners are tracked, disposed on teardown, and one-time events do not linger.
- Checklist-pass findings with BAD vs GOOD pattern replacements
- Concrete dispose/onWillDispose fixes for flagged subscriptions
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Memory-leak review is canonical on the Ship shelf because leaks surface under real usage and block stable releases. Review subphase matches PR-style audits and leak reports before merge or patch release.
Where it fits
Before merging a new panel widget, verify every DOM and emitter subscription is registered via _register/addDisposableListener.
Run the checklist on a PR that adds icon or theme toggles reported to leak listeners after dozens of clicks.
After production reports of sluggish UI, trace repeated setup methods that never dispose old handlers.
How it compares
A pattern checklist for disposables—not a heap profiler substitute or generic React useEffect lint pass.
Common Questions / FAQ
Who is memory-leak-audit for?
Indie and solo developers building VS Code–style extensions or event-heavy TypeScript clients who need systematic leak review.
When should I use memory-leak-audit?
At Ship review when auditing PRs with listeners; during Build frontend work when adding subscriptions in widgets; when fixing reports of climbing listener counts after toggles or navigation.
Is memory-leak-audit safe to install?
It is guidance-only for review; check this page’s Security Audits panel and treat agent-suggested refactors like any other code change.
SKILL.md
READMESKILL.md - Memory Leak Audit
# Memory Leak Audit The #1 bug category in VS Code. This skill encodes the patterns that prevent and fix leaks. ## When to Use - Reviewing code that registers event listeners or DOM handlers - Fixing reported memory leaks (listener counts growing over time) - Creating objects in methods that are called repeatedly - Working with model lifecycle events (onWillDispose, onDidClose) - Adding event subscriptions in constructors or setup methods ## Audit Checklist Work through each check in order. A single missed pattern can cause thousands of leaked objects. ### Step 1: DOM Event Listeners **Rule**: Never use raw `.onload`, `.onclick`, or `addEventListener()` directly. Always use `addDisposableListener()`. ```typescript // BAD — leaks a listener every call this.iconElement.onload = () => { ... }; // GOOD — tracked and disposable this._register(addDisposableListener(this.iconElement, 'load', () => { ... })); ``` **Validated by**: PR #280566 — Extension icon widget leaked 185 listeners after 37 toggles. ### Step 2: One-Time Events **Rule**: Use `Event.once()` for events that should only fire once (lifecycle events, close events, first-change events). ```typescript // BAD — listener stays registered forever after first fire model.onDidDispose(() => store.dispose()); // GOOD — auto-removes after first invocation Event.once(model.onDidDispose)(() => store.dispose()); ``` **Validated by**: PRs #285657, #285661 — Terminal lifecycle hacks replaced with `Event.once()`. ### Step 3: Repeated Method Calls **Rule**: Objects created in methods called multiple times must NOT be registered to the class `this._register()`. Use `MutableDisposable` or return `IDisposable` to the caller. ```typescript // BAD — every call adds another listener to the class store startSearch() { this._register(this.model.onResults(() => { ... })); } // GOOD — MutableDisposable ensures max 1 listener private readonly _searchListener = this._register(new MutableDisposable()); startSearch() { this._searchListener.value = this.model.onResults(() => { ... }); } ``` When the event should only fire once per method call, combine `Event.once()` with `MutableDisposable` — this auto-removes the listener after the first invocation while still guarding against repeated calls: ```typescript private readonly _searchListener = this._register(new MutableDisposable()); startSearch() { this._searchListener.value = Event.once(this.model.onResults)(() => { ... }); } ``` **Validated by**: PR #283466 — Terminal find widget leaked 1 listener per search. ### Step 4: Model-Tied DisposableStores **Rule**: When creating a `DisposableStore` tied to a model's lifetime, register `model.onWillDispose(() => store.dispose())` to the store itself. ```typescript const store = new DisposableStore(); store.add(model.onWillDispose(() => store.dispose())); store.add(model.onDidChange(() => { ... })); ``` **Validated by**: Pattern used in `chatEditingSession.ts`, `fileBasedRecommendations.ts`, `testingContentProvider.ts`. ### Step 5: Resource Pool Patterns **Rule**: When using factory methods that create pooled objects (lists, trees), disposables must be registered to the individual item, not the pool class. ```typescript // BAD — registers to pool, never cleaned per item createItem() { const item = new Item(); this._register(item.onEvent(() => { ... })); return item; } // GOOD — wrap with item-scoped disposal createItem(): IDisposable & Item { const store = new DisposableStore(); const item = new Item(); store.add(item.onEvent(() => { ... })); return { ...item, dispose: () => store.dispose() }; } ``` **Validated by**: PR #290505 — Chat content