ModuleServiceWorker

[ghazale-hosseinabadi]

Ya ya yawm TAG!

I'm requesting a TAG review of ModuleServiceWorker.

Chromium supports three types of workers: Dedicated Workers, Shared Workers, and Service Workers. Importing ES modules has been implemented and shipped for Dedicated Workers, but not for Service Workers. We'd like to launch importing ES modules for service workers, since Service Workers are the foundation of PWAs (Progressive Web Apps) and should support importing ES modules to provide the new PWA features.

• Explainer¹ (minimally containing user needs and example code): https://docs.google.com/document/d/1SeQ085YdBTtW3D_ygSpO0Wz2DAe8QiS1gj37IG5lstg/edit#
• Specification URL: https://w3c.github.io/ServiceWorker/#service-worker-concept
• Tests: https://docs.google.com/document/d/1aw1sELxXt7usIdkDPYwW0DDOQhpN1ZBuCCSy-XKBtiM/edit
• Security and Privacy self-review²: n/a
• GitHub repo (if you prefer feedback filed there): n/a
• Primary contacts (and their relationship to the specification):
  • Ghazale Hosseinabadi (ghazale-hosseinabadi), Google
  • Asami Doi (d0iasm), Google
  • Hiroki Nakagawa (Nakagawa-Hiroki), Google
  • Matt Falkenhagen (mfalken), Google
• Organization(s)/project(s) driving the specification: Google
• Key pieces of existing multi-stakeholder review or discussion of this specification: n/a
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://www.chromestatus.com/features/4609574738853888

Further details:

• [ Yes] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: [please provide]
• The group where the work on this specification is currently being done:
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue):
• Major unresolved issues with or opposition to this specification: n/a
• This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify [github usernames]

[kenchris]

Is this different from what was implemented in Safari: https://trac.webkit.org/changeset/273224/webkit/ @hober

[ghazale-hosseinabadi]

No, it is the same. We are implementing it for Chrome.

[torgo]

@ghazale-hosseinabadi Thanks for this! Quick request: we noticed that the explainer link is actually pointing to a design doc. Can you please produce an explainer that starts with documentation of the user need? We've produce a guide on what this should generally look like. Also this should ideally be a markdown file which sits next to the spec. We're focused on starting with user need - in this case, I think it would be something like "service workers allow users to do x, y, z.. with this added feature users will now be able to do a, b, c." That would greatly help with the review process. Great to see the multi-stakeholder support for this, by the way! 👍🏻

[ghazale-hosseinabadi]

@d0iasm Since you are the author of the "ES Modules for Service Workers", do you want to convert it to a .md? I can also do it. Please let me know. Thanks!

[kenchris]

@ghazale-hosseinabadi make sure it talks about the Web Platform feature only. Chromium related parts can be left out

[ghazale-hosseinabadi]

@torgo @kenchris Where should I upload the markdown file? https://w3c.github.io/ServiceWorker/ or https://source.chromium.org/chromium? Thanks!

[wanderview]

@ghazale-hosseinabadi I recommend putting it in a service worker github issue in this case. Or maybe even in the existing issue for service worker modules with a note at the top saying "here is an explainer for the TAG review" or something.

[plinss]

Ideally the explainer should be in the repo along side the spec.

Also note, the explainer isn't just for the TAG, it's for everyone who wants a quick introduction to the spec, as well as capturing important information that doesn't necessarily belong in the spec, such as motivations, alternatives considered, etc. Having that helps everyone working on the spec in the future that wasn't in the room when it was first developed.

[wanderview]

Yes, but this is a case where the feature was discussed, reached consensus, and already spec'd in an established wg repo. (And indeed even implemented in two browsers.) The issue where the feature was discussed and where consensus was reached should already contain all the information. The one I recommended is the repo where it is spec'd.

[wanderview]

In retrospect, I think @ghazale-hosseinabadi linked an implementation design document in the TAG review. The best explainer, though, is probably the spec issue where this was discussed, consensus was reached, and it was spec'd:

w3c/ServiceWorker#831

[torgo]

@wanderview sorry this dropped off our radar. I take your point re: the explainer, however what you linked to really doesn't provide the level of info we talk about in our explainer explainer. We're really suggest that every TAG reviews should include an explainer that starts with (end) user needs - clearly described.

[kenchris]

The TAG is happy with this feature but closing with resolution satisfied with concerns due to the lack of an actual explainer