Why is context-storage in hono itself rather than being carved out to third-party middleware?

[re-taro]

The context-storage added in Hon v4.6.0, which allows secure access to the context from outside the handler, is very nice. It's just what we wanted.

However, we ask this question because we have doubts about its implementation and the way it is provided.

I see that context-storage is achieved by relying on AsyncLocalStorage in node:async_utils. I thought this was a deviation from Hono's policy of web standards. Reading through the code, it was felt that the only runtime-dependent code written in hono is the @hono/middleware implementation and the adapter layer.

I would like to know if there is any thought or background as to why this is implemented in this way.

[yusukebe]

Hi @re-taro

As you said, Web Standards APIs do not include AsyncLocalStorage. But it is implemented in major runtimes: Cloudflare Workers(workerd), Deno, Bun, and Node.js. So, I decided to make it built-in middleware that is easy to use without installing another @hono/* package. Context Storage Middleware is just middleware, so users don't use it if they don't want to depend on non-Web Standards API.

Actually, for those runtimes, AsyncLocalStorage is not an external library but a built-in API. It can say the same thing about Cache Middleware. It uses a Cache API, which is not a Web Standards minimum set. For example, it's not implemented in Node.js and Bun, though workerd and Deno have it. But including it as built-in middleware makes it useful and portable.

Plus, AsyncLocalStorage is proposed to be WinterCG minimum spec: https://github.com/wintercg/proposal-common-minimum-api/blob/main/asynclocalstorage.md (though It's just a proposal).