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.
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.
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
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)