Adding Go's defer to the TypeScript Compiler

func withSemaphore(ctx context.Context, sem *semaphore.Weighted) error {
if err := sem.Acquire(ctx, 1); err != nil {
return err
}
defer sem.Release(1)
// ... protected work
return nil
}

async function readFile(path: string) {
await sema.acquire();
try {
// ... use resource
} finally {
sema.release();
}
}

But that's kinda ugly.

For fun, we can hack in a defer statement to the TypeScript compiler and get Go-like semantics. Since defer doesn't map to an existing JavaScript feature, we need to output JavaScript code that makes it work at runtime just like it does in Go.

So the goal is to be able to write TypeScript code like this:

async function readFile(path: string) {
await sema.acquire();
defer sema.release(); // New!
// ... use resource
}

The TypeScript Compiler

The TypeScript compiler (tsc) is mostly a static analysis engine. Its complexity lies in type-checking a fundamentally dynamic language, and supporting extremely incremental compilation to meet latency expectations in an IDE.

Lucky for us, we don't need to worry too much about types or other analysis in order to add our defer statement. tsc already has the machinery for "recognize syntax X, replace it with equivalent syntax Y."

For example, when compiling for ES5:

class Foo {
x = 1;
}

Might become something like:

function Foo() {
this.x = 1;
}

Conceptually, adding defer means doing another tree rewrite. tsc already performs a number of AST-to-AST transformations (e.g. optional chaining ?. becomes conditional expressions) so we don't need to add new tooling.

There's some complexity to dig into, but at a high level, we'll take an AST with defer:

function f() {
defer cleanup();
work();
}

And transform it into something like:

function f() {
const __defers = [];
try {
__defers.push(() => cleanup());
work();
} finally {
// Pop and invoke
}
}

First, we need to teach tsc's parser that defer is a statement. There's a list of syntax kinds that we add DeferStatement to and we define it as taking a single expression operand.

There are a few checks we need to perform, like ensuring the defer statement appears inside a function body, making sure that the expression is callable, and ensuring tsc performs its usual recursive checks:

func (c *Checker) checkDeferStatement(node *ast.Node) {
c.checkGrammarStatementInAmbientContext(node)
// A defer is tied to the lifetime of its containing function
fn := ast.GetContainingFunction(node)
if fn == nil || fn.Body() == nil || !ast.IsBlock(fn.Body()) {
c.grammarErrorOnNode(node, diagnostics.Defer_statements_can_only_be_used_inside_function_bodies)
} else if ast.GetFunctionFlags(fn)&ast.FunctionFlagsGenerator != 0 {
c.grammarErrorOnNode(node, diagnostics.Defer_statements_cannot_be_used_in_generators)
}
// Only calls are supported, which keeps capture/lowering unambiguous
expression := ast.SkipParentheses(node.Expression())
if !ast.IsCallExpression(expression) {
c.grammarErrorOnNode(node.Expression(), diagnostics.The_operand_of_a_defer_statement_must_be_a_call_expression)
c.checkExpression(node.Expression())
return
}
// Reuse normal call checking (callable callee, argument types, etc.)
c.checkExpression(expression)
}

The actual transformation code is quite verbose so rather than reproduce it here, I'll instead dig into the design decisions I made and tell you more about how the transform works.

How I Think defer Should Work

To match Go's behavior, the callee, receiver, and argument values are captured immediately:

let x = 1;
defer console.log(x);
x = 2;

This must print 1.

An extreme case we need to survive is the callable method being redefined like:

const logger = {
log(message: string) {
console.log("old:", message);
},
};
defer logger.log("hello");
// Everything changes after the defer
logger.log = (message) => {
console.log("new:", message);
};

Even if logger.log is reassigned later, the deferred call still invokes the original method. This matches Go's semantics, where the function value, receiver, and arguments are all evaluated when execution reaches the defer statement.

Any function that contains at least one defer gets a small stack, and each reached defer statement pushes a closure onto that stack. When the function exits, the stack is drained in reverse order (last-in-first-out).

Registration happens when execution reaches the defer, not when the function starts. So a defer inside an if only runs if that branch ran, and a defer inside a loop registers once per iteration.

So a user writes:

async function readFile(path: string) {
await sema.acquire();
defer sema.release();
return await fs.readFile(path, "utf8");
}

Which is transformed like:

async function readFile(path) {
const stack = [];
try {
await sema.acquire();
const receiver = sema;
const method = receiver.release;
// Register cleanup only if execution reaches the defer statement.
stack.push(() => method.call(receiver));
return await fs.readFile(path, "utf8");
} catch (error) {
// Save the original error so cleanup can still run.
} finally {
// Run registered callbacks in reverse order.
// In an async function, await each cleanup before moving to the next one.
// If cleanup also throws, aggregate the failures.
}
}

Rather than invent semantics for defer await, I simply reject it as an error. I worried that a user would assume that the await would resolve before the rest of the function runs. Besides, if the containing function is async, every deferred call is awaited sequentially during cleanup.

More On Errors

The cleanup code can fail too, so the transform follows three rules:

• Every deferred call runs, even if an earlier one throws.
• The original error from the function body is preserved.
• If multiple errors occur, they are reported with an AggregateError.

Go doesn't need an aggregation policy like this because ordinary errors are values. A deferred call's returned error is not handled unless the user explicitly decides to do something with it. JavaScript exceptions are control flow. So when the compiled defer code throws an error it needs to decide whether that replaces, combines with, or is ignored in favor of the original failure.

Since async functions turn both throws and rejected awaits into promise rejection, the transform needs one clear rule for both sync throws and async cleanup rejections:

async function f() {
defer asyncCleanup();
throw new Error("body");
}

If asyncCleanup() also rejects/throws, f() rejects with an AggregateError.

AggregateError([
Error("body"),
cleanupError,
]);

So Let's Ship It?

Ironically, implementing defer convinced me it doesn't belong in TypeScript.

The more edge cases I implemented, the less convinced I became that defer belongs in TypeScript. Go's defer feels way more natural because errors are values rather than control flow. In TypeScript, once cleanup can throw or reject, you need policies for aggregation, precedence, and async execution that simply don't exist in Go (panics are handled through Go's separate panic and recover semantics).

But hope is not lost. The ECMAScript Explicit Resource Management proposal tackles the same problem from a different direction.

Take the async-sema example from above, instead of defer:

async function readFile(path: string) {
await sema.acquire();
defer sema.release();
return await fs.readFile(path, "utf8");
}

We can use a Disposable:

async function readFile(path: string) {
using _ = await acquirePermit(sema);
return await fsReadFile(path, "utf8");
}
// The above assumes a helper like this,
// which could be embedded in the library
async function acquirePermit(sema: Sema): Promise<Disposable> {
await sema.acquire();
return {
[Symbol.dispose]() {
sema.release();
},
};
}

I would prefer not to have to define an unused variable like _ but disposable resources work by cleaning them up when they fall out of scope.

So my preferred but sadly unsupported syntax would be:

async function readFile(path: string) {
using await acquirePermit(sema); // Not supported!
return await fsReadFile(path, "utf8");
}

You can find the MVP implementation of defer on this branch of my TypeScript fork.