Static import of custom code

[timroes]

You currently can only use importScripts to insert some custom logic to the serviceworker script.

Since importScripts() involves making additional requests (and for maybe several other reasons), it would be nice, if there would be an option in which you can specify additional files and their content is added to the generated service-worker.js when building the file. That way you could extend the generated SW file without the need of using importScripts().

[jeffposnick]

I'm inclined to tell you and other to stick with importScripts() here, since it's very much a case of using a platform feature for the purpose it was intended. Proper HTTP caching headers on the imported scripts can cut down on additional network traffic.

If you're in a situation in which it's technically impossible to accomplish what you'd want with importScripts(), i.e. you need to trigger the SW update flow when your code changes, then one workaround is to maintain your own modified copy of service-worker.tmpl, and pass that in via the templateFilePath option. This unfortunately can make it the process of migrating from one version of sw-precache to another trickier, as the contents of that template file are, to some degree, tied to a given version.

You mentioned having several reason why importScripts() isn't desirable, and I'm definitely willing to entertain this if the other reasons are showstoppers. My general outlook at this point is that sw-precache's options are getting a bit unwieldy, and I'm reluctant to add in additional ones when there are existing ways of getting similar results.

[timroes]

Due to the problem with migration to newer sw-precache versions I tried not to fork the service-worker.tmpl.

The main problem I am currently having with importScripts() is, that I didn't find any clear documentation how service worker behaves, in case these request fails. How does it influence the installation of the service worker?

And I also fear, since serviceworker are already quite complex to test (manually and/or automatically) even though the Chrome Dev Tools has made an immense progress for service workers, which I really like, that importScripts() wouldn't make the testing and troubleshooting progress easier.

[jeffposnick]

Yeah, the service worker-specific documentation on importScripts() is a little lacking, partly because it's a function that predates service workers, and was developed for plain old web workers.

The best technical description probably comes from the HTML Spec. The most _import_ant bits are that if the imported script throws an exception, that gets propagated up to the service worker's scope. And if fetching the script initially fails, that also throws an exception.

If an unhandled exception is throw during service worker installation, originating from importScripts() or directly within the service worker's global scope, then the service worker installation will fail.

The one wrinkle with a service worker's usage of importScripts() is that it after service worker installation completes, it implicitly caches the files, the same way it implicitly caches the top-level service worker script file. So while it will attempt to re-fetch the scripts the next time the service worker starts up, if re-fetching fails, it won't throw an exception—it will just reused the internally cached copy. This is explained in the service worker spec, but it's not particularly obvious—the talk of a "script resource map" refers to this internal cache.

[timroes]

Thanks for the information. So if you are against the static import, we could close this ticket?

[jeffposnick]

Yup! Hopefully that all sounds reasonable. Also, when #147 is implemented, it will be much more straightforward for developers to "own" their top-level service worker, and then just pull in sw-precache itself via importScripts().