Service worker fails to load new dynamic/code-split chunk

Is this a bug report?

Yes

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

Yes

Which terms did you search for in User Guide?

progressive web app service workers

Environment

1. node -v: 8.4.0
2. npm -v: 5.6.0
3. yarn --version (if you use Yarn):
4. npm ls react-scripts (if you haven’t ejected): 1.0.17

Then, specify:

1. Operating system: Windows 10
2. Browser and version (if relevant): Chrome 63

Steps to Reproduce

1. Set up a default CRA project
2. Install react-loadable to code-split a certain React component on the page
3. Build, serve and navigate to the page
4. Modify the component earlier (to change the generated hash)
5. Build, serve and reload the page

Expected Behavior

The new version of the code-splitted component should be loaded correctly.

Actual Behavior

The installed service worker tries to fetch the old component chunk instead of the new one, resulting in a failure to load the new chunk. This is because the hash has changed since the last time the service worker was installed. Because of this react-loadable interprets the error and refuses to display the new page, resulting in a blank page.

This is less than ideal, and the only thing I could come up is to force a reload on the homepage. This will trigger the new service worker to be installed which results in the correct component/chunk being loaded.

[peterbe]

Ash @jeffposnick said, talking about service workers here is just making things more confusing. Same problem, just harder to see.

Another good solution is to “cake on the built assets”. Running yarn run build will wipe out any old ./build/ directory but on your server, you can keep the old files from the old deployment.

If the Monday build was:

1. build/static/js/main.aaa.js
2. build/static/js/chunk.111.js

…and someone loads main.aaa.js on that Monday but don’t click the button that causes chunk.111.js to load yet.

Tuesday’s build was:

1. build/static/js/main.bbb.js
2. build/static/js/chunk.222.js

So if that Monday user eventually tries to load chunk.111.js it’s going to be gone. It would be better if your server (e.g. Netlify, S3, Nginx, whatever) would be available to host all of…:

1. build/static/js/main.aaa.js
2. build/static/js/chunk.111.js
3. build/static/js/main.bbb.js
4. build/static/js/chunk.222.js

that you would avoid that 404 error.

Having to reload the page just because a chunk failed feels dangerous. What if the user is in the midst of typing in their shipping address and a reloaod causes all sorts of disruption to the shopping cart checkout process.

[rovansteen]

I feel your pain. I’ve been thinking about it a lot but it’s hard to come up with a unified solution as this is mostly an issue with the hosting providers. Using something like Cloudflare to cache all your bundles on their servers (up to a month) could help if you don’t have full control over the hosting of your application.