Closed Qard closed 3 years ago
@vdeturckheim thanks for the update and for doing the work to get it out of experimental. I think its a really important feature and appreciate you moving it forward.
+1 for making non-experimental. We are applying it in a production environment.
For the past two months I've been working with AsyncLocalStorage
as a runtime for a full-stack web framework (https://github.com/midwayjs/midway). It has made Using "React Hooks" to develop the back-end
into a reality.
Referenced code: https://github.com/midwayjs/hooks/blob/ecc0b83a4fae5554cfbec8e61ca6ba74bc3f6135/packages/hooks-core/src/runtime/index.ts#L1-L23
We have over 1000 Midway full-stack applications in our company and will be upgrading to use the AsyncLocalStorage
version. So it is very important for us that AsyncLocalStorage becomes a stable Api.
+1 for making this non-experimental. We at Airlift are also seriously considering it for our production environment.
We stabilised a subset of the API that should be prod ready in https://github.com/nodejs/node/pull/37675 :)
@vdeturckheim I think maybe we should close this for now as "complete" and open a new one to stabilize other parts at a later time when that makes sense?
+1 @mhdawson . cc @Qard too?
We've stabilized what I wanted to see stabilized, so I'm going to call this done. Other parts of async_hooks, or more likely further higher-level APIs on top of it, can have their own stability timeline discussions elsewhere.
The
AsyncResource
API has been largely unchanged since its creation many majors ago, andAsyncLocalStorage
has been out in the wild for awhile now and has proven its utility. I think both should be considered for stable status at this point. The challenge I see is that they live in theasync_hooks
module which has been marked as "experimental" at the top-level because theasync_hooks
feature itself exposes internals thus many (myself included) were unwilling to accept it as a "stable" API.What I suggest is that
AsyncResource
andAsyncLocalStorage
be considered as stable in the next major. Due to the module being named after the one not stable feature, it may also be worth moving the two APIs out to new top-level modules, but I'll leave that last point for discussion.How should we proceed in getting these two APIs to stable status?
cc @nodejs/diagnostics