fix: Avoid changing the URL of the service worker.

[bmeurer]

According to the official documentation[1], it's bad practice to change
the URL of the service worker. Also there's not really a point in having
time stamped URLs for the sw-register.js script. This also allows to
simplify the registration quite a bit, leading to less JavaScript to
parse and execute for the browser.

[1] https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle

[PengXing]

The original intention of sw-register.js is that we don't want developers care about the cache-control: no-cache header of sw.js. I think that is a little complicated.

The URL of sw.js in sw-register.js gets update using a new suffix which is BUILD_TIME, when you build project. And loading fresh sw-register.js using CURRENT_TIME as suffix, every time when user refreshes their pages. So, sw.js can get updated immediately once you re-deploy your project, without setting any response headers of any files.

If you can set cache-control of sw.js, you don't even need the sw-register.js file.

[bmeurer]

But why do you want to disable caching? That way you loose the benefits of caching for both .js files?

[PengXing]

If don't disable caching of sw.js, service worker won't get updated immediately.

[bmeurer]

I see, thanks.

[jakearchibald]

The no-cache thing shouldn't be an issue now https://developers.google.com/web/updates/2018/06/fresher-sw.

The problem with changing the URL is it treats it as a new service worker even if nothing's changed.

[PengXing]

@jakearchibald Thanks. I didn't notice that this problem has been fixed since Chrome 68. I created a new issue #19, and I'll remove sw-register.js when it's Chrome 68+.