Add worker modules

[domenic]

/cc @ajklein @DigiTec @Constellation @jonco3

Builds on top of the editorial #607 (the first commit), and split into two commits for easier reviewing. This is a pretty simple spec, with most of the complication being in threading the CORS-awareness of modules through workers.

These commits also make it very easy to add CORS support to non-module workers, if people are interested in that while they are mucking around with this area of their implementation. If so let me know and I can tack on another commit doing so.

/cc @jungkees since you are probably going to want to do some of this for service workers too.

[annevk]

When you pass "omit" here it's not a crossOrigin mode. How about we name this WorkerModuleCredentialsMode and moduleCredentials as member (or just credentials as all new features will require the opt-in anyway)?

[domenic]

You don't pass omit. It mirrors the crossOrigin IDL attribute/crossorigin="" content attribute: missing (null) = omit, anonymous = same-origin, use-credentials = include.

We could use fetch()'s RequestCredentials enum, but I thought it'd be better to stick with the terms and API from HTML. WDYT?

[annevk]

It seemed a little ugly to me to reuse that for a new API. Nullable enum still feels wrong. Workers happen to be in HTML, but that's it.

[domenic]

One advantage of the existing setup is that we can use null to mean different defaults if we extend CORS to classic workers (there null -> same-origin, for back-compat). I guess we could do that with the new scheme though too; we just use RequestCredentials? credentials = null and determine what null means based on classic vs. module.

I'm happy to switch this to RequestCredentials credentials = "omit" for now if you think that's best for new APIs.

[domenic]

Fixed in a separate commit.

[annevk]

I was worried we would not be setting origin and referrer correctly but since we have the correct environment settings object I think that will all work fine.

I was thinking that if we do not change classic workers we might entice folks to upgrade to module workers sooner since they can be hosted on a CDN.

For service workers the main service worker script is required to be same-origin. There are no restrictions on importScripts() however. So perhaps some kind of flag on "fetch a module script tree" that forces the initial fetch to be same-origin is needed.

[domenic]

@ajklein @DigiTec @Constellation @jonco3 can I get some comments on this? Is this something we should add to the spec, and you are interested in implementing as you work on modules? Would really be great to get everyone's opinions here.

[ajklein]

There's no doubt that support for modules in Workers is something I, as an implementer (in Chromium/Blink/V8), want to make available on the web. I think most of the interesting bits of this proposal, though, have to do with the API, not with implementation concerns.

Workers are less constrained than script tags, since they don't have to interact with the HTML parser and the page-loading system. This might make us wish for a constructor that defaults to module mode, rather than having to pass a second argument to get the module behavior (of course this comes down to a naming problem).

I'm also not sure that we want to expose importScripts() on the global scope of module workers, as that could well be confusing to future programmers.

[domenic]

Thanks for commenting @ajklein!

My intention was for workers, shared workers, and service modules all to be module-ifyiable. If we introduce a new worker constructor, and a corresponding new type of WorkerGlobalScope, I don't think we accomplish this---or at least we cause a small combinatorial explosion as we add (Shared|Service)Worker(Module)(GlobalScope). I also don't think the ergonomic benefits of new WorkerModule(s) over new Worker(s, { type: "module" }) are strong.

I'd be up for disabling importScripts inside module workers though. I thought it would be good to allow it so that people can continue to use things like the service worker cache polyfill (which is not authored as a module) but maybe that's short-term thinking.

[DigiTec]

FYI this has our interest ;-) I've read the diffs and I don't see anything that would pose difficulties for our implementation. I think the only open question is whether or not we should continue to allow importScripts.

Thinking through use cases. I have a worker and I want to import another module, but I don't have access to imperative module loader APIs yet. In the HTML spec, you can start a new module root with script type="module" but workers don't have the same option unless we update importScripts to allow a module type as well. This thinking is also likely short-term as more pieces of modules land.

So I'd be okay removing importScripts in the type="module" worker in order to simplify things. It does mean that worker modules are effectively 100% declarative until module loader APIs come along unless i'm missing something else.

[domenic]

Awesome, thanks @DigiTec!

It sounds like there's a collective weak leaning toward disabling importScripts for modules, at least for now. I'll work on updating things in that direction (but keep the commit around in case @Constellation or @jonco3 feel strongly we should keep importScripts). Note that I'll just make importScripts throw a TypeError immediately in a module worker, instead of trying to create some new type of WorkerGlobalScope.

@annevk, I'll ping this thread again when that's ready for editor review. Regarding

For service workers the main service worker script is required to be same-origin. There are no restrictions on importScripts() however. So perhaps some kind of flag on "fetch a module script tree" that forces the initial fetch to be same-origin is needed.

I think we should leave that for the time when service workers does the integration work, so we can have a discussion on the service worker repo where you educate me as to why it has to be same-origin even with CORS :).

[jonco3]

This looks good to me.

I agree with @ajklein about importScripts. I don't think this really make sense for module workers.

[ajklein]

@domenic I'll buy that given the wealth of different worker constructors an options arg is probably the lightest way to go. Thanks for expanding on that.

[domenic]

@annevk ready for review! importScripts now throws a TypeError in module workers. (Which, for the record, turns out to be a better name than "worker modules", because "worker classics" doesn't work.)

[annevk]

s/can/need to/

[domenic]

@annevk pushed a fixup1 commit addressing your feedback.

[annevk]

LGTM then. The reason service workers require same-origin by the way is to ensure that the domain itself controls the service worker. If the service worker could be controlled by another domain that would make XSS even uglier since the domain might never find out it lost a bunch of users to that other domain.