Asynchronous module loading via top-level `await` breaks SharedWorkers "connect" event

Chrome has support for a feature called SharedWorkers. This allows you to run a process in the background shared between multiple tabs with the same origin. It's essentially a small extension over a webworker. The key difference between the two is that SharedWorkers have a "connect" event which fires when a new tab creates a reference to the shared worker.

Unfortunately, this event ("connect") is sent after the SharedWorker's code is evaluated but before the async function's promise resolves. Fixing this upstream in Chrome is the right solution... but I suspect not really an option in the mid-term.

I've been trying to think of what a good workaround would be... Possibly in a SharedWorker the "connect" event could be intercepted and forwarded on after async evaluation is resolved. I'm not entirely sure.

I am at least sure of this: without a solution, you can't really use SharedWorkers with WASM. (Except through some pretty gnarly hacks.)

Start by reproducing the issue in Chrome with a SharedWorker that uses asynchronous module loading via top-level await and observe when the "connect" event fires. Investigate whether the plugin can provide a reliable workaround without relying on an upstream Chrome change; done means SharedWorkers can use WASM modules without timing hacks.