Reputation: 10664
I am trying to use a service worker file which is also an ESM module.
The register
method has an extra argument accepting an options
object which has a type
field whose valid values seem to be classic
and module
, but when I use:
navigator.serviceWorker.register('worker.js', { type: 'module' });
// `worker.mjs` doesn't work either
// The file exists in both cases!
I get an unspecified DOMException
with no message in Chrome.
I figured what the valid values for type
were by reading the spec, specifically this:
https://html.spec.whatwg.org/multipage/workers.html#workertype
It seems to me like my code is valid.
As a sanity check, I also tried to explicity set type
to classic
and the service worker registration then goes through fine. If I set it to an invalid value, I get a TypeError
telling me so, so it's not like the browser is not yet aware of type: module
. It is treated as a special case, it just throws a DOMException
with no message.
Am I using the type
field correctly? Is it still too early and it is not supported in browsers?
Upvotes: 3
Views: 2115
Reputation: 10664
This is dumb! Chrome will print just DOMException
into the console (not even expansible) when logging the error object and Object.keys
on that object instance returns []
, but when I specifically print e.message
the culprit is revealed:
type 'module' in RegistrationOptions is not implemented yet.See https://crbug.com/824647 for details.
Not amused by Chrome.
Upvotes: 5
Reputation: 1075537
On browsers, bare names can't be used to identify modules unless you also have a module map (aka import map, this link has much more info) that maps the bare name to a module.
If worker.js
is in the same location as the page loading it, then:
navigator.serviceWorker.register('./worker.js', { type: 'module' });
// -------------------------------^^
Or of course, add a module map.
Upvotes: 2