Library Affected: workbox-sw, workbox-webpack-plugin
Browser & Platform:
"all browsers"
Issue or Feature Request Description:
I am using workbox-webpack-plugin with InjectManifest plugin. I use mini-css-extract-plugin to extract my css into a separate file. For long term caching, I use contenthash in my filename but looks like workbox is not able to detect it and creates revision field for it. Thereby, re-downloading the css everytime any of my js changes.

This is similar to https://github.com/GoogleChrome/workbox/issues/1102#issuecomment-352066934
I'm happy to leave this open to reinvestigate whether there's a clean solution, but the last time I looked into this, we were blocked because our plugin had no way of knowing about the hashes created by other plugins.
@jeffposnick
Looking at the OPs screenshot, I note that a revision field was correctly omitted for *.js files containing a _full hash_ in the name.
However, if using an abbreviated hash ([chunkhash:<number>]), e.g.
// webpack.config.js
output: {
filename: "[name]-[chunkhash:6].js" // e.g. app-a1b2c3.js
}
...a revision field is created for the *.js files as well.
This is because hash detection currently works by looking for 'known hashes' in the webpack compiliation (compilation.hash, compilation.fullHash, etc.); but doesn't account for the case when those hashes are intentionally shortened in the asset names.
If there's no easy solution to the issue underlying problem (such as webpack exposing an asset.isHashed property that Workbox can interrogate), do you think it would it be worth relaxing hash detection to a substring match of the first 5 characters (rather than an exact match) to account for these cases?
e.g.
if (!revision || knownHashes.some((hash) => url.includes(hash.substr(0,5))) {
Right, so there are what I think are two different scenarios:
[chunkhash:6] or the equivalent. This is something that we could allow developers to tell us about via a config option, and I've filed a feature request to track that: https://github.com/GoogleChrome/workbox/issues/1458This will be something you can accomplish in Workbox v5 by passing in a RegExp to the dontCacheBustURLsMatching config option.
Unfortunately, detecting it automatically without providing that option is not feasible for the v5 timeline.
This should be addressed by the current Workbox v5.0.0 alpha.