Cache busting (hashing) mechanism for webpack bundled assets


#1

I’ve set up an XP site with webpack bundling my client src (js and css) into assets. I fetch them with assetUrl.

http://myapp.example.com:8080/_/asset/com.example.myapp:1540718802/styles/main.css
http://myapp.example.com:8080/_/asset/com.example.myapp:1540718802/scripts/main.js

The assetUrl function adds what seems like the build timestamp, meaning my users will have to reload these assets every time I deploy a new build. Perhaps not the end of the world, but nonetheless sub-optimal.

I know I could address the assets directly, bypassing the assetUrl method, but that would leave my users with old cached versions, which is even more problematic.

What I would like is to have a hash on the files. Webpack can generate this hash, but what would be the best way to tell my XP page controller (or html template) about the generated file name? I use webpack 4.

Alternatively, does XP have a hash mechanism I can use in conjunction with the assetUrl function?

How do others solve this?


#2

There are several options you could go for. Off the top of my head:

  1. You could have a direct reference to assets (without assetUrl), intercept requests to asset folder in a site controller and then manually cache assets inside the controller with our lib-cache lib.
  2. You could use WorkboxJs, either workbox-build plugin or workbox-webpack-plugin plugin (the last one is specifically tailored for Webpack build). It can generate the manifest of assets matching specific regex, with a specific hash for each asset file, which you can then use for your needs (browse the list, get the hash, generate unique asset path etc.)

https://developers.google.com/web/tools/workbox/reference-docs/v3.0.0/module-workbox-build#.getManifest


#3

I smell a feature request here! If we simply create a hash-list for all assets build-time, we could replace the current app-timestamp with asset hash without modifying any of the current functionality. If the hash-list is missing, we simply fallback to current solution.

Like?


#4

Thank you both! Thomas, your proposal of shipping this within XP is very tempting. It would improve rendering time for most installations!