Had to do this to avoid a race condition where every test thought it could start the InspectorProxyWorker on 9229 because get-port doesn't work across processes (jest workers, in this case)

We confirmed this affects wrangler dev and unstable_dev if you run multiple processes in parallel where get-port thinks the requested port is available but then there's a race for all the workerd instances to bind to it

We have a fix coming in a follow-up

TODO: make miniflare surface "port in use" errors so wrangler can retry instantiating Miniflare with port 0

Adding to this public interface so we can fake some startDevWorker events (call the event listeners)

TODO add getBindings to this interface

This class contains the glue code for all startDevWorker controllers. This is the contract between all controllers. You could override the instances of each/any controller in the constructor but we're not exposing this to users yet until we're more sure of the contract.

The types from devtools-protocol don't expose the full object we see in the websocket messages, just the sub-properties for some reason

This file may seem daunting but it just coerces the types into the whole object we see – e.g. with method and params matched together not as separate type unions which is basically useless

@mrbbot got nerd-sniped and got it working 👏

This is (essentially) the entry-point to wrangler dev – here we create a DevEnv and map the props into StartDevWorkerOptions (at least what is relevant for now – for ProxyController) and fake events by calling ProxyController event handler methods (devEnv.proxy.on*)

The user worker now never starts on https, and binds to 127.0.0.1 on a random port. The ProxyWorker will start on the previous address values

No more preview server or inspector server, replaced by ProxyWorker and ProxyInspectorWorker respectively

This outer function (startDevServer) is called internally by unstable_dev. Here we create a DevEnv and fake events to the ProxyController by calling it's event handler methods (devEnv.proxy.on*)

This is one of those fake async libs where they provided a node.js callback signature for ecosystem consistency. It makes no difference to call it without a callback ("synchronously") but this way we can de-async the callstack

Alternatively, could we take advantage of the existing async nature of this function to use an ESM await import()? Reducing synchronous require()s will be helpful with things like e.g. a future move to Viteste

I think await import() segfaults in Jest, breaking our existing tests 🙁

Declaring the type for worker: prefix module imports. We added an esbuild plugin to find these worker files in packages/wrangler/templates/*

Synchronously returning this promise. The promise will resolve later when we process the queue.

Any possible things running that would depend on this Promise? Considering possible race conditions or the like.

pause events cause the ProxyWorker to buffer requests

play events cause the ProxyWorker to begin proxying requests to the UserWorker (using proxyData)

The ProxyWorker can communicate back to the ProxyController via this service binding

Not awaiting this fetch means we replay the requests in order but we don't guarantee their delivery in order. We could await just the headers (not the body) to guarantee delivery order too but I don't think it matters too much – happy to hear other opinions

If you are chaining then & catch, why is the void necessary?

It shouldn't be a floating promise or anything, if its been chained with a catch I mean.

Just being explicit about not awaiting the promise since we're in a loop and it's on purpose

But I guess I could just add a comment instead

Is there any reason not to await the fetch? We're already creating an ordered buffer of requests, we might as well make sure that the delivery order is preserved

The main reason is that if the UserWorker has any long-running requests and therefore requires parallel request handling, await-ing would prevent that.

I've left a comment stating, if we choose to await, we should also race it against a timeout of e.g. 100ms

This resolves the promise returned by the initial fetch handler

This rejects the promise returned by the initial fetch handler

This is a big boi, sorry

It's job is to proxy messages between the runtime inspector (#websockets.runtime), ProxyController (#websockets.proxyController) and devtools client (#websockets.devtools).

Because only one client can be connected to the runtime inspector server, the InspectorProxyWorker is essentially that one client. The ProxyController and devtools then can both connect to the InspectorProxyWorker.

I'm a bit unclear on the use-case for chaining deferreds. If a deferred gets inherited, any holder of the previous deferred loses control over its lifecycle (the resolvers become inert since its promise has now already been resolved). Similarly, if the previous deferred has already been resolved before it gets inherited, the new deferred isn't allowed to extend the lifecycle of the previous one.

So whether or not a holder of a deferred maintains control over its lifecycle, and whether or not its lifecycle has been extended is unreliable. This seems error-prone and like it would lead to some insidious bugs.

If a deferred gets inherited, any holder of the previous deferred loses control over its lifecycle (the resolvers become inert since its promise has now already been resolved)

True

Similarly, if the previous deferred has already been resolved before it gets inherited, the new deferred isn't allowed to extend the lifecycle of the previous one.

True

So whether or not a holder of a deferred maintains control over its lifecycle, and whether or not its lifecycle has been extended is unreliable. This seems error-prone and like it would lead to some insidious bugs.

The point is not to extend the lifecycle of the old promise. It's to ensure the old promise is not left uncompleted. If the old promise is already completed (resolved/rejected), this line has no effect