Workers and non-JavaScript modules

[dandclark]

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

Consider this example:

const worker = new Worker('resource.json', {type:'module'});

Per the run a worker algorithm, this would Fetch a module worker script graph which, given that resource.json came with a JSON MIME type, would create a JSON module script. The JSON module script would be returned to the run a worker algorithm, which would call run a module script, which would call Evaluate() on the JSON Module Script’s Synthetic Module. 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 steps passed to Fetch a module worker script graph by the 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 imports), where others do not (CSS modules, HTML modules).

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

[annevk]

We should probably have been a little more careful here. Top-level JavaScript and Wasm make sense to me, others not that much.

[littledan]

An analogous case: <script type=module src="config.json"></script>. This is pretty useless, but also harmless. The current specification allows it. I'd say we should make a common decision between workers and script tags.

I'm comfortable with the current approach. It feels vaguely more consistent to me, as it helps us from refraining to specially call out the top-level module as a specific concept.

[justinfagnani]

If we provide a way to get a module from a <script> tag (like a .module getter), then things like <script type=module src="config.json"></script> might become useful in some cases.

[littledan]

@justinfagnani Is this idea under discussion somewhere?

[justinfagnani]

@littledan mostly casually. We talked about it at the spring web components face-to-face in the context of the HTML modules proposal.

[caridy]

I do agree with @justinfagnani, we should have such getter, or any other form of referencing the module namespace object.

[domenic]

I would be happy with taking a conservative approach and disallowing JSON/etc. for workers and script elements for now, and loosening that up later if we ever add a .module or similar. But, I would also be happy treating it as relatively harmless and letting folks do it.

If we want to restrict it, we should decide sooner rather than later, because I can just imagine the kind of fun hacks people will start using this for. (E.g. precaching JSON files, or something weirder...)

[annevk]

A related thing here is that we cannot support certain module types in a worker context (e.g., CSS and HTML) and perhaps also not in a worklet context.

[littledan]

OK, sounds like treating script tags and workers as the same is a bit of an oversimplification. I can see the case for restricting JSON modules in workers while leaving them in place for script tags.

[Jamesernator]

A related thing here is that we cannot support certain module types in a worker context (e.g., CSS and HTML) and perhaps also not in a worklet context.

Is there a major reason Document/HTMLDocument aren't supported in Workers? Obviously self.document is a no-go but I see no reason the documents created by documentImplementation.{ createDocument, createHTMLDocument } shouldn't be usable.

[annevk]

DOM implementations in browsers are not thread-safe and nobody is willing to put in the effort to make them so. (And to be clear, I don't think we've seen compelling enough use cases to justify the enormous amount of effort required.)