What does `using` / `await using` do for Explicit Resource Management (ES2024)?

Q: What does `using` / `await using` do for Explicit Resource Management (ES2024)?

**Target Audience:** Engineers preparing for JavaScript fundamentals interviews. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every disposal order and error-path claim below was actually run natively in Node — this feature genuinely runs without a transpiler. ## 1. Why This Even Matters — A Story First Checking several items out of a library one at a time and being trusted to return each one yourself is genuinely error-prone — forgetting even one leaves it un-returned indefinitely, especially if something interrupts your visit early (a real emergency, an error). A librarian who automatically, genuinely takes every checked-out item back the moment you leave the building — in the REVERSE order you picked them up, and even if you had to leave in a hurry — is exactly what `using` provides for resources like file handles, database connections, or locks. ## 2. The Core Idea 📌 **Inter

The problem

Question presented to candidate: "If you declare using r1 = resource1, then using r2 = resource2 inside a block, and an error is thrown right after — do the resources still get cleaned up? And in what order?"

What a strong answer should cover:

📌 Interview term: using declaration — declares a resource that must implement [Symbol.dispose](); the engine genuinely, automatically calls that method when the enclosing block exits — normally OR via an early return/break/thrown error.
📌 Interview term: the real, direct answer to the prompt's first question — verified directly: a real error thrown right after declaring a using resource genuinely still triggers disposal — the resource's [Symbol.dispose] ran correctly BEFORE the error propagated to a surrounding catch block.
📌 Interview term: the real, direct answer to the prompt's order question — verified directly with 3 real resources: disposal genuinely happens in strict reverse declaration order — the LAST-declared resource is disposed FIRST, mirroring a real, standard stack-unwinding discipline.
📌 Interview term: await using — the async counterpart, for a resource implementing [Symbol.asyncDispose]() instead — verified directly: the surrounding async function genuinely does not fully resolve until the async disposal itself has been correctly awaited.
A precise answer names DisposableStack/AsyncDisposableStack as the real, companion container types this proposal also introduces — a stack-based way to register MULTIPLE disposable resources together programmatically, beyond individual using declarations — confirmed directly to exist as real, defined globals alongside Symbol.dispose/Symbol.asyncDispose.

Clarifying questions expected:

None — this is a definitional/technical question; directly answering both halves of the prompt (disposal-on-error, and reverse order) with real proof is the strong signal.

Code / implementation expected: Yes — real proof of both disposal-on-error and strict reverse-order disposal with 3 real resources is the clearest, most convincing demonstration.

es2024
using
resource

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript fundamentals interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every disposal order and error-path claim below was actually run natively in Node — this feature genuinely runs without a transpiler.

1. Why This Even Matters — A Story First

Checking several items out of a library one at a time and being trusted to return each one yourself is genuinely error-prone — forgetting even one leaves it un-returned indefinitely, especially if something interrupts your visit early (a real emergency, an error). A librarian who automatically, genuinely takes every checked-out item back the moment you leave the building — in the REVERSE order you picked them up, and even if you had to leave in a hurry — is exactly what using provides for resour

The solution is hidden so you can try first

5 min read · 8 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal proof: using genuinely disposes a resource even when an error is thrown, and disposes multiple resources in strict reverse declaration order