Leverage `using`/`Symbol.dispose` to ensure resources are cleaned up before Node.js exits

[brillout]

What is the problem this feature will solve?

Today, there isn't a way to guarantee resource cleanup. For example:

export function doSomeWork() {
    const path = ".some_temp_file";
    const file = fs.openSync(path, "w+");

    try {
        // use file...

        if (someCondition()) {
            // do some more work...
            return;
        }
    }
    finally {
        // Close the file and delete it.
        fs.closeSync(file);
        fs.unlinkSync(path);
    }
}

If the process exits between fs.openSync() and the finally code block, then the file isn't removed.

What is the feature you are proposing to solve the problem?

While a 100% guarantee isn't possible, leveraging the new using keyword, there is an opportunity to dramatically increase the probability of successful resource cleanup.

Is that on Node.js's radar?

What alternatives have you considered?

No response

[climba03003]

Is that on Node.js's radar?

You can see multiple pull request already working on it and most of them are merged.

The first iteration of Symbol.dispose is released on 20.4.0, but the using keyword requires v8 support.
https://bugs.chromium.org/p/v8/issues/detail?id=13559
https://bugs.chromium.org/p/v8/issues/detail?id=13879

[brillout]

Very neat.

the using keyword requires v8 support.

Makes sense. A workaround is to use TypeScript 5.2 which supports using.

[silverwind]

Would such a cleanup work even when v8 crashes like in heap out of memory cases, e.g. when no JS execution is possible any more.

[MoLow]

Would such a cleanup work even when v8 crashes like in heap out of memory cases, e.g. when no JS execution is possible any more.

Probably not

[silverwind]

Would such a cleanup work even when v8 crashes like in heap out of memory cases, e.g. when no JS execution is possible any more.

Probably not

I guess it would if the cleanup is performed in C++. That would be a truly reliable way for cleanup as the process exit hook is not triggered on V8 crash, but I guess another way to declare the resources will be needed as JS can not execute anymore then unless v8 is restarted which I would not advice to do.

[benjamingr]

Hey,

Great to see users are asking for this!

As others have mentioned this is "on the roadmap" and we started adding Symbol.dispose and Symbol.asyncDispose support to all APIs. You can using timers, readable streams, file handles and mock timers so far.

We've done this in collaboration with the TypeScript team and coordination with Babel so users in transpilers would be able to benefit from it before V8 lands the syntactic support.

When the process crashes, electricity goes down or another catastrophic failure happens you cannot rely on disposers running. It is effectively a safer/neater alternative for try... finally.

[silverwind]

When the process crashes, electricity goes down or another catastrophic failure happens you cannot rely on disposers running. It is effectively a safer/neater alternative for try... finally.

Is there a difference between v8 crashing and node crashing? Couldn't node still run cleanup before exiting in case of v8 crash?

[benjamingr]

I'm wondering if we should ship a defer helper since you can absolutely await using the file in your case which would close it but you would have to wrap it or try/finally it in order to also unlink it.

[benjamingr]

Is there a difference between v8 crashing and node crashing? Couldn't node still run cleanup before exiting in case of v8 crash?

My point is that users cannot rely on app-level cleanup code running in all cases since we (and any other platform) cannot guarantee that it will run. There are some cases where cleanup will run (e.g. unhandled rejection since it would propagate through the stack and disposers would run) and some cases where they won't (e.g. segfault).

[benjamingr]

What APIs would you expect support in other than streams/files @brillout ?

[brillout]

Thanks for the ping. My only use case so far is clear up of temporary files, but I'm sure there are other use cases that I can't think of right now.

(Unrelated but since you're Node.js member, I wonder whether the Node.js team can influence the outcome of npm/rfcs#665? It's a really bad situation. It's causing massive pain on a daily basis to Node.js users. If we can find a solution that would significantly address the reputation of "JavaScript is a mess".)