rxjs-leak-finder vs @ngneat/until-destroy
They solve different halves of the same problem. until-destroy prevents leaks — if you remember the operator on every subscription. rxjs-leak-finder finds the ones you forgot. Here's how they differ and why most teams want both.
The short version
@ngneat/until-destroy is a prevention tool: decorate a component with @UntilDestroy() and pipe each stream through untilDestroyed(this), and Angular tears the subscription down on ngOnDestroy. It works — as long as you apply it to every subscription, in every component, forever.
rxjs-leak-finder is a detection tool. It patches the RxJS Observable prototype in dev mode and reports the subscriptions that were never torn down — including the ones where you forgot untilDestroyed. It does not unsubscribe for you; it tells you where the leaks are so you can fix them.
So the real question is not "which one" — it's "how do I know my prevention actually worked?" until-destroy is the seatbelt; rxjs-leak-finder is the crash test.
Feature comparison
| Capability | rxjs-leak-finder | @ngneat/until-destroy |
|---|---|---|
| Primary job | Detect leaked subscriptions | Prevent leaks (auto-unsubscribe) |
| Catches subscriptions you forgot to manage | ✅ Yes — that's the point | ❌ No — only what you decorate |
| Per-subscription boilerplate | None | untilDestroyed(this) on every stream |
| Per-component setup | One line in main.ts, app-wide | @UntilDestroy() decorator per component |
| Works outside components (services, interceptors) | ✅ Patches the prototype globally | ⚠️ Needs a manual destroy notifier |
| Runtime cost in production | None — inert unless enabled in dev | Ships in your bundle, runs in prod |
| Shows leak source (stack trace) | ✅ Captures subscribe() call site | ❌ N/A |
| Standalone / signals-era Angular | ✅ Works regardless | ✅ Works |
Accurate as of June 2026. until-destroy behavior per its official README — corrections welcome via an issue.
When until-destroy is enough
If your team is disciplined and your app is small, the untilDestroyed pattern can cover you. The failure mode is human: a new teammate subscribes without it, a refactor drops the operator, or a stream lives in a service where this has no ngOnDestroy. None of those raise an error — the leak is silent until memory climbs.
When you also want rxjs-leak-finder
Run rxjs-leak-finder in dev to verify that until-destroy is doing its job. If the dashboard shows zero leaks, your prevention is working. If it lights up, it points to the exact subscribe() that slipped through — usually one nobody knew about.
// main.ts (dev only)
import { isDevMode } from '@angular/core';
import { enableRxjsLeakDetector } from 'rxjs-leak-finder';
if (isDevMode()) {
enableRxjsLeakDetector();
}FAQ
Is rxjs-leak-finder an alternative to until-destroy?
Not a replacement — a complement. until-destroy stops leaks; rxjs-leak-finder confirms none slipped past. Many teams keep until-destroy and add rxjs-leak-finder as the dev-time safety net.
Can I drop until-destroy and just use rxjs-leak-finder?
You still need some teardown strategy (takeUntilDestroyed, manual unsubscribe(), or until-destroy). rxjs-leak-finder finds the gaps; it doesn't close them for you.
Does it slow my app down?
Only in dev. It captures a stack trace per subscribe() — negligible during development, and inert in production because you gate it behind isDevMode().
Related: vs takeUntil / takeUntilDestroyed · vs SubSink · How to find RxJS memory leaks