[w3c/webcomponents] Workers and non-JavaScript modules (#822)

I’m wondering about the expected behavior for non-JavaScript module types with regards to workers.

Consider this example:
```JavaScript
const worker = new Worker('resource.json', {type:'module'});
```

Per the [run a worker](https://html.spec.whatwg.org/multipage/workers.html#run-a-worker) algorithm, this would [Fetch a module worker script graph](https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-module-worker-script-tree) which, given that resource.json came with a JSON MIME type, would [create a JSON module script](https://html.spec.whatwg.org/multipage/webappapis.html#creating-a-json-module-script).  The [JSON module script](https://html.spec.whatwg.org/multipage/webappapis.html#json-module-script) would be returned to the [run a worker algorithm](https://html.spec.whatwg.org/multipage/workers.html#run-a-worker), which would call [run a module script](https://html.spec.whatwg.org/multipage/webappapis.html#run-a-module-script), which would call [Evaluate()](https://heycam.github.io/webidl/#smr-evaluate) on the JSON Module Script’s Synthetic Module.  [Evaluate()](https://heycam.github.io/webidl/#smr-evaluate) won’t do anything except set the parsed JSON object as the default object of the module, which is essentially a no-op in this scenario as there is no importing module to observe it.  So, this effectively becomes a Worker that just doesn’t do anything.

Is this by-design?  It is a little odd but perhaps not harmful.  An alternative would be to ban non-JavaScript MIME types for the top-level Worker module, perhaps in the custom [perform the fetch](https://html.spec.whatwg.org/multipage/webappapis.html#fetching-scripts-perform-fetch) steps passed to [Fetch a module worker script graph](https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-module-worker-script-tree) by the [worker processing model](https://html.spec.whatwg.org/multipage/workers.html#worker-processing-model) steps.  On the other hand, it seems reasonable for descendants of the top-level Worker module to be non-JS, e.g. a Worker should be able to `import config from “./config.json”`.

These questions will gain further relevance with the introduction of other module types.   I think this will need to be a case-by-case thing where some module types make sense in a Worker context (JSON modules, WebAssembly, [GetOriginals](https://github.com/domenic/get-originals) imports), where others do not (CSS modules, HTML modules).

@littledan, @domenic, @annevk, @travisleithead, any thoughts?


-- 
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/webcomponents/issues/822