Re-use of project as browser polyfill?

[rektide]

Hello. I've been thinking about re-creating the async_hook capabilities for the browser, in whatever kind of limited fashion. It would be interesting to me to try to create observability points for promises, and Node's async_hook seems like the only standard we have for that at the moment.

How much of this project (at 0.7.1, it's last release) do you think is still applicable, or useful, if one wanted to shim Node's async-hooks?

Do you have any thoughts surrounding asyncId's, which are extensive in the Node API but absent here? How close to implementable are those in userland?

Making the Embedder API available would be another key feature of a good browser implementation of async_hook. Do you have any thoughts on how that may be mated to the work in this project?

[AndreasMadsen]

A big problem we faced was that async functions don't depend on global.Promise but instead the internal [[Promise]]. It is thus not possible to instrument async function in the browser. In node.js we collaborated with the V8 team to create a C++ API for this. So I don't think this can be done.

How much of this project (at 0.7.1, it's last release) do you think is still applicable, or useful, if one wanted to shim Node's async-hooks?

No much. The timeout patches are properly fine, but the rest can't really be reused. And the browser has a huge API surface.

Do you have any thoughts surrounding asyncId's, which are extensive in the Node API but absent here? How close to implementable are those in userland?

This module had asyncId's. Implementing asyncId is simple if you already have all the events. It is just a number that increments for every init event.

Making the Embedder API available would be another key feature of a good browser implementation of async_hook. Do you have any thoughts on how that may be mated to the work in this project?

The Embedder API is also simple. It will just be an abstraction upon the internal API you will need to create for the patches.