Re: [w3c/ServiceWorker] Top-level await integration for ServiceWorkers running modules (#1407)

@jakearchibald I'm suggesting that we don't set up such blocking mechanics, and instead, just launch execution of the module and go right on our way in setting up the ServiceWorker. Concretely, in the [Run Service Worker](https://w3c.github.io/ServiceWorker/#run-service-worker-algorithm) algorithm, in step 12, we'd just run the module, take the Promise that it returns, and more or less discard it, continuing on our way with the setup.

There's a small amount of complexity with errors during module execution: Although errors are communicated via Promises, the JS specification knows about synchronous errors synchronously, in a way that doesn't break Promise invariants, and we could thread through an API to query this state, or you could just cheat and check if the Promise was rejected. If there's an error after a top-level await, that'd come via an `onerror` event "later", after the Service Worker is already running.

Does this setup make sense to you? Or do you see some reason why we'd still have to block?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1407#issuecomment-503142715