importScripts are cached forever

[radiofrequency]

When I push a new version of the service worker, it gets updated but it doesn't reload any changes in files imported via ImportScripts.

Maybe there should be a feature to load scripts and inline them into the service-worker.js when swPrecache is building instead of using ImportScripts that i assume rely on browser caching mechanism?

[jeffposnick]

As of right now, you're responsible for configuring the HTTP cache directives used by your web server when responding to requests for URLs listed in importScripts. If you were to disable HTTP caching on the responses, they'll be fetched fresh from the network each time.

This behavior is due to the way the browser deals with the underlying importScripts() method, rather than due to any specific logic in sw-precache.

That being said, the maintainers of the service worker specific have realized that obeying HTTP cache directives for service worker scripts can be problematic, especially in hosting scenarios that don't give developers control of configuring them. There has just been a change made to the service worker specification that will prevent both the main service worker script as well as anything pulled in from importScripts() from going against the HTTP cache, unless you explicitly opt-in to using the cache.

Neither Firefox nor Chrome have shipped a version of their browsers that adhere to the new behavior yet, but both are working on it.

Given that there's a solution that will be generally available in the future, I don't think it makes sense to modify sw-precache at this point to start doing things like inlining importScripts directly in the generated service worker.

[radiofrequency]

My push handler, web workers and toolbox etc are part of my service worker and should be reloaded when there is a service worker update. Because of the design of swPrecache the only way to modify the service worker output is to override the template file which isn't easy to maintain. A simple option to inline some files into your service worker would make swPrecahe much easier to work with as everyone is going to want to add a push handler and get caught by this gotcha. Anyways appreciate your response.

[jeffposnick]

If you serve the .js files that define your push handler, web workers, etc. with something like a Cache-Control: max-age=0, no-cache HTTP response header, then all of those files will be retrieved fresh from the network, ensuring that your service worker picks up any changes that you deploy. (Assuming that there's a network connection; if the network is unavailable, the previous version of those imported scripts will still be reused, in spite of the HTTP caching directives.)

Inlining the files listed in importScripts is not on the table for sw-precache, but we're thinking about this use case for the next generation of service worker libraries. The current plans are described at GoogleChrome/workbox#61 This will move towards a model where developers can have full control over their top-level service worker file, while still taking advantage of automatic file versioning.

[radiofrequency]

Ok good to know a solution is in the works. For my use case I need to modify the service worker so I need to override the template file and each time you make a release I need to merge my changes back in. I wasn't suggesting to change importScripts just to add a new option to load some scripts into the service worker to avoid overriding the template files. Thanks for the info on the http cache.