Keep .js chunks from old deploys

I have an issue with static js files is removed after deploy. I use code spitting to some components in my app (https://reactjs.org/docs/code-splitting.html).

The app is a web app, and some users have “installed” it on their home screens to use it as a native app.

When lazy loading parts of the web app, a user may browse around during a deploy. All .js chunks are replaced with new hashes when I deploy. When the user (with the old app) now navigates to some functionality that needs to load a chunk, the chunk with that hash does not exists on the server anymore.

So for currently loaded client, the chunk does not exist. Error: Loading chunk 7 failed.

For tech savvy users using the app in a browser, they can just refresh. But for those users who are using the app “installed” on their home screen, they can’t reload the page.

One solution would be to force refresh the app when a chunk fails to load, like this solution How to retry when React lazy fails - DEV Community 👩‍💻👨‍💻

But in addition, it would be great to keep old js chunks on the server for a while.

Is there a way to deploy a react app without wiping the old static files (except those that are overwritten, of course)?

Hi, @stianlp. Our deploys are “atomic” so that the old assets are expired when the new deploy is publish. There is more information about this here and here.

The only way I know of to keep the previous files active would be to include them in the publish directory of the new deploy.

Keeping the old files active is the opposite behavior of what Netlify will do by default and there is no automatic method for doing this.

The best solution I can think of is to have the site javascript check the version of the deployed site (using the etag header for some file, for example /index.html) and force an update of all assets when the etag changes.

You might also copy all files from all previous deploys to the new deploy but, again, this runs contrary to Netlify’s design and there is no automated solution do this.

If there are other questions about this, please let us know.

Hello Luke,

I feel that there is a use case to keep serving assets from old deploys, especially immutable assets

We deploy our app 5/10 times a day (we develop an internal platform), some of them don’t need a refresh (design, small fix, etc.), but with the current set up, it breaks in the scenario described by stianlp. We already handle force refreshing when necessary, but it happens every other day on average

I think there could be a way to declare immutable assets in netlify.toml (we have a regexp to enable browser long term caching in our case), and serve those assets even after version change, since they could not be modified anyway

Copying assets from version to version would create very large deploys, but I’ll have a look on it

What do you think?

We would be happy to know if this feature makes it to your roadmap

Thank you!

Yup, your use case makes sense, but our system won’t support it directly very soon. I prefer the solutions mentioned in this thread, to copying the files around: [Support Guide] Why do I see “Uncaught SyntaxError: Unexpected token <” errors? How can I use chunking or versioning for my assets at Netlify?

I also had this issue and put together a plugin to get around the problem.

I totally agree that precaching is a great option, but there’s no guarantee a client browser will support service workers (or precache all the assets in time)

Hope this helps some of you!

2 Likes

Thanks so much for circling back to this thread, @andyrichardson! Knowledge sharing is part of what makes the Netlify Forums a helpful place :netliconfetti:

1 Like