This is something that I mentioned early on in this project but I'm creating this issue now to track it.
Currently, we are creating the module runner inside a Worker, despite the fact that the module runner is stateful and Workers are required to be stateless. As our HMR implementation requires a persistent WebSocket connection this leads to the following error in some scenarios (e.g. when using import.meta.hot.send in the fetch handler):
Cannot perform I/O on behalf of a different request. I/O objects (such as streams, request/response bodies, and others) created in the context of one request handler cannot be accessed from a different request's handler. This is a limitation of Cloudflare Workers which allows us to improve overall performance. (I/O type: Native)
Others have tried to circumvent this by running user Worker code inside a Durable Object rather than a Worker. I don't think this is the right solution, however, as this would also allow user code to do things that would break in production.
This may turn out to be a bit of a non-issue as frameworks may have no need to send events from inside the request handler. It is possible to send and receive events when import.meta.hot is used outside the request handler and tests were added for this in #70.
This is something that I mentioned early on in this project but I'm creating this issue now to track it.
Currently, we are creating the module runner inside a Worker, despite the fact that the module runner is stateful and Workers are required to be stateless. As our HMR implementation requires a persistent WebSocket connection this leads to the following error in some scenarios (e.g. when using
import.meta.hot.sendin thefetchhandler):Cannot perform I/O on behalf of a different request. I/O objects (such as streams, request/response bodies, and others) created in the context of one request handler cannot be accessed from a different request's handler. This is a limitation of Cloudflare Workers which allows us to improve overall performance. (I/O type: Native)
Others have tried to circumvent this by running user Worker code inside a Durable Object rather than a Worker. I don't think this is the right solution, however, as this would also allow user code to do things that would break in production.
This may turn out to be a bit of a non-issue as frameworks may have no need to send events from inside the request handler. It is possible to send and receive events when
import.meta.hotis used outside the request handler and tests were added for this in #70.