How to reset all built js chunks hashes and purge clients' cache?

[nullday0]

I had some situation when there was an internal error on express side and it returned some broken response.
I used proposed in remix's examples 1y cache:

  app.use(
    '/build',
    express.static('public/build', {
      immutable: true,
      maxAge: '1y',
    }),
  )

So, the client got this broken response cached on their end.
AFAIK, the only way to purge it is to change build files hashes, changing paths to all js files in build folder.

How can I achieve this? It seems like hash changes only if file was actually modified, so I have to modify all the files in order to do that, which doesn't look right.
I would like to have some way to purge all hashes on every deployment making sure that I have no clients with bad code cached.
Any ideas will be appreciated 🙏

[richardscarrott]

Sounds painful. Quick fix would be to change the build output path from the default public/build to something else in your remix config, e.g. public/buildv2 -- https://remix.run/docs/en/main/file-conventions/remix-config#assetsbuilddirectory.

Pretty worrying to think something as widely used as express static would have a bug that could cause this. To mitigate any future risk, you should prob consider pushing your public directory to a CDN / static hosting.

[nullday0]

It's not a bug from express, it's just a set of circumstances that led to such state of my project.

Thanks for your input, I think it's a good idea, I can programmatically adjust assetsBuildDirectory before building remix, it will allow me to add any suffix to build folder.

[richardscarrott]

It's unlikely you'll want to change it on every build as you lose the benefits of long term caching on assets which haven't changed in the build -- for example if you only modify one route, all the other chunks are likely to remain unchanged so can continue to be read from cache.

[Erij-Maherzia-BEN-BRAHIM]

Instead of relying on file modification time for cache-busting, consider using versioned file names. This means changing the file names themselves whenever you make changes. For example, you can include a version or a timestamp in the file name, such as app-v1.0.0.js. This way, even if the file content doesn't change, the browser treats it as a different resource due to the different file name.

In your deployment process, you can automate the renaming of files or include a build step that generates versioned file names.

[nabeelpkl]

@Erij-Maherzia-BEN-BRAHIM any sample code for the same ?