Yes
Yes
node -v: 8.2.1npm -v: 4.6.1yarn --version (if you use Yarn): 1.2.1npm ls react-scripts (if you haven鈥檛 ejected): empty
Operating system: Windows 10 Pro Insider Preview Build 17025 64Bit
(Write your steps here:)
npm run build or yarn buildlocalhost:5000 in ChromestaticCacheName variable in build/sw.js and reload page in chromeExpected the new Service Worker to be "waiting to activate" in Chrome Dev Tools Application tab.
New Service Worker is quickly flashing up as installing but vanishes again shortly after.
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.
@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.
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:
c-r-a to recommend serve -s -c 0 build to host locally with caching disabled.serve to get /sw.js and /service-worker.js exempted from caching by default when serve -s is used: https://github.com/zeit/serve/issues/299serve, which seems like a big change to make.Thank you so much for looking into it!
Most helpful comment
You're seeing this because
serveis adding in HTTPCache-Controlheaders tosw.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
servewas 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
servecontinues to cache everything by default, and also continues to be the tool recommended bynpm run build's output, then that will lead to a lot more folks bumping up against this in Chrome, which is not good.