Service Worker Bug in Production, works in dev.

[J4K0B]

Is this a bug report?

Yes

Can you also reproduce the problem with npm 4.x?

Yes

Environment

1. node -v: 8.2.1

2. npm -v: 4.6.1

3. yarn --version (if you use Yarn): 1.2.1

4. npm ls react-scripts (if you haven’t ejected): empty

5. Operating system: Windows 10 Pro Insider Preview Build 17025 64Bit

6. Browser and version (if relevant): Chrome: 62.0.3202.94 Firefox: 57.0

Steps to Reproduce

(Write your steps here:)

1. clone and install https://github.com/J4K0B/CryptoMemesClient
2. run npm run build or yarn build
3. open localhost:5000 in Chrome
4. change staticCacheName variable in build/sw.js and reload page in chrome

Expected Behavior

Expected the new Service Worker to be "waiting to activate" in Chrome Dev Tools Application tab.

Actual Behavior

New Service Worker is quickly flashing up as installing but vanishes again shortly after.

Additional Information

Doing the same steps leads to the intended behaviour in Firefox.
If I hit Update in Chrome Dev Tools application tab, the App works as expected.
Editing the file in the public folder while in dev mode leads to the intended behaviour in Chrome after hot reload, too.

[gaearon]

@jeffposnick

[jeffposnick]

You're seeing this because serve is adding in HTTP Cache-Control headers to sw.js, and Chrome (still, unfortunately 😦) honors those headers. Firefox no longer honors them.

Back when service worker generation was added to this project, I'm fairly positive that serve was not locally caching anything by default, which led to the type of local "staging" experience that matched what's recommended for development.

I'm going to take a look through https://github.com/zeit/serve/releases and https://github.com/pillarjs/send/releases (which appears to handle the HTTP communications under the hood) to figure out when this behavior changed, and whether it was intentional.

If serve continues to cache everything by default, and also continues to be the tool recommended by npm run build's output, then that will lead to a lot more folks bumping up against this in Chrome, which is not good.

[jeffposnick]

It looks like this is due to serve -s (SPA mode) being used. The caching defaults for that mode changed back in July (commit), which made it into the 6.0.1 release of serve.

There are a few different options:

1. Update c-r-a to recommend serve -s -c 0 build to host locally with caching disabled.
2. Work with the folks who maintain serve to get /sw.js and /service-worker.js exempted from caching by default when serve -s is used: Disable /service-worker.js and /sw.js caching in SPA mode? vercel/serve#299
3. Recommend something other than serve, which seems like a big change to make.
4. Disable service worker registration, which also seems like a big change to make.

[J4K0B]

Thank you so much for looking into it!