Add sw-cache snippet to the bottom of the template with fingerprinted path

[HoneyryderChuck]

BEFORE YOU SUBMIT please read the following:

• I'm submitting a bug report
• I'm submitting a feature request
• [ x] I'm submitting a support request

webpack version:
2.5

sw-precache-webpack-plugin version:
0.9.2

Please tell us about your environment:
OSX 10.x

Current behavior:

I'm currently using sw cache plugin to load the sw cache worker. I'm following the instructions there (copy the snippet to the bottom of the page:

 <script>
	if ('serviceWorker' in navigator) {
		 navigator.serviceWorker
			  .register("/sw-cache.js")
			  .then(function() {
			      console.log('Service worker registered!');
			  })
			  .catch(function(error) {
			      console.log('Error registering service worker: ', error);
			  });
	} 
</script>

Expected/desired behavior:

Current behaviour is fine, but doesn't take advantage of contenthash resource names from webpack. Now, creating the fingerprint sw cache is easy, injecting it in the template is not. Is there a way to use webpack to inject the snippet with the proper production "sw-cache.js" path?

My main issue with this is that, whenever I release a new version of a pwa app with new assets, loading the cached sw-cache is loading the invalidated set of assets.

[goldhand]

Can you use an environment variable for the .register(PATH)?

Btw, you need to specify cache-control: no-cache header on the service worker. Maybe neeed to draw more attention to that somewhere in the readme

[HoneyryderChuck]

Can you use an environment variable for the .register(PATH)?

I guess not. Webpack contains the information about the generated build file names, so I'd say this is a build-time decision. That'd be the same as manually updating my template before updating the server. The idea is to make it dynamic, or at least "at build time" decision.

Btw, you need to specify cache-control: no-cache header on the service worker.

It's true, this might solve part of the issue. Or even setting Max-Age to 0. The thing is, will this still be necessary if the sw files are fingerprinted? Shouldn't this cache invalidation mechanism suffice?

[goldhand]

Just thinking on this, if one were to cache their main index.html, where the service worker, service-worker.v1.js is registered, then we try to deploy a new build, service-worker.v2.js, index.html still points to service-worker.v1.js, so I don't think we will be able to install the new service worker, preventing any new builds from being deployed.

[HoneyryderChuck]

Well, I guess that's an entirely different problem, which is out of scope here. Are you delivering the template as is? Are you rendering it through smth like express? Not the issue to address here