Re: [w3c/ServiceWorker] Clarify dynamic-imported scripts are never installed (#1356)

hmm, stumbled upon an issue today that i'm trying to work my way around, 
i'm trying out the new `type=module` in service worker today... it's awesome 👍 

But today i got stuck with "top-level await is not supported in chrome".

I know that your goal of all is to make it all work offline no matter what.
And you should only be allowed to register listeners on installation, and never later, bla bla bla

Even doe I disagree with you on some points... cuz all they is are pain points.

You could always implement your own event emitting algoritm on top of the of an another listener to be able to circumvent this lazy registration.
```js
const ET = new EventTarget
self.onfetch = () => {
  const evt = new Event('fetch')
  ET.dispatchEvent(evt)
}

// sometime later
setTimeout(() => {
  ET.addEventListener('fetch', () => { ... })
}, 1000)
```
or create some sort of pipeline
```js
const middlewares = [ before, handler, after ]
self.onfetch = evt => {
  evt.respondWith(async () => {
    let response
    for await (let pipe of pipeline) {
      response = pipe(response) 
    }
    return response
  })
}

// sometime later - add a prehook to the middleware array
setTimeout(() => {
  middlewares.unshift(fn)
}, 1000)
```

So I don't see any reason to block this functionality of lazy event registration when developers can circumvent this anyway in some way or the other that is more a painful experiences.
why i'm i bringing this up? well, it isn't my original issue with top level await that i was faced with today... I haven't read the spec from top to bottom of how it currently work (bad lazy jimmy) but maybe it could have something to do with how you register event listener on installation. 

if i'm importing something in a "sync" manner with top level import, and one of the files use top level await to acquire something from IndexedDB that it's dependent upon then i think that should be allowed as well

i rather want to acquire something once, then having to do it every time in a fetch event
```js
const cacheStorage = await caches.open('v1')
const authKey = await idb.get('key')
/** @type {FileSystemDirectoryHandle} */
const rootHandle = await idb.get('root')

self.onfetch = evt => {...}
```
over this pattern:
```js
self.onfetch = evt => {
  evt.respondWith(async () => {
    const cacheStorage = await caches.open('v1')
    ...
  })
}
```

and there is going to be cases where i wish to conditionally load a polyfill if something isn't supported so again, being forced to import something that isn't needed (b/c it has to be fetched and work offline) with top level import statment is just a waste of bandwidth and time, i rather want to be able to do:
```js
var polyfills = []
if (!Array.prototype.groupBy) polyfills.push(import('./array-prototype-groupBy.js'))
if (!Array.prototype.at) polyfills.push(import('./array-prototype-at.js'))

await Promise.all(polyfills)
```
vs 
```js
import './array-prototype-groupBy.js'
import './array-prototype-at.js'
```

---

today i'm building something that should be working offline and requires heavy use of service worker + whatwg/fs to function.
so i always need to get the handle from the indexeddb... no way around that. that's why i wanted to have top level await

My point is: I think ServiceWorker are unnecessary heavenly restricted to what a normal Web Worker can do.
This restriction is actually causing my Service Worker to behave worse as if i would have support for top-level await and also dynamic lazy `import(path)`.

"By preventing developer shooting them self in the left foot then they shot themself in the right foot instead..."

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1356#issuecomment-1059824060

You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1356/1059824060@github.com>