Workbox: New webpack plugin config option to specify hash length

[jeffposnick]

Library Affected:
workbox-webpack-plugin

Moved over from https://github.com/GoogleChrome/workbox/issues/1454#issuecomment-385608719

workbox-webpack-plugin attempts to determine whether an asset already includes a hash in its filename, and won't cache-bust requests for assets that do include a hash.

Unfortunately, we don't have a ton of context from the webpack build process to determine whether an asset has a hashed filename or not, and while we can detect full hash usage, we can't safely infer when developers use, e.g., [chunkhash:6] to only use a substring of the hash.

Rather than try to automatically guess, what we could do is add in a new config parameter for workbox-webpack-plugin called hashSubstringLength (or an alternative name, if there are objections). If set, we'll check asset filenames against all the full knowns hash, as well as the substring of each hash with the length specified.

Developers would need to know to manually set this, but it's something that could be automatically included as part of CLI/framework integrations that use a constant hash substring length.

[freezy]

Why not use a regex for cache busting like dontCacheBustUrlsMatching used to in v2?

[tmchng]

I believe it will be much easier if you let the developers specify string or regex that they wish to match. For instance:

dontCacheBustUrlsMatching: [
  '[hash:6]',
  '[chunkhash:8]',
  /\.[a-zA-z\d]{5}\./
]

Edit: I'm not sure if this is possible, just food for thought.

Edit2: After some rough research, looks like it can be done.

For example, we could borrow hash interpolation logic from the webpack loader-utils, and this would allow us to accommodate various hash and digest types.

I feel that the workbox-webpack-plugin is currently making some assumptions around caching that don't necessary apply to most use cases. Two that I've came across so far:

1. Assumes that all webpack-generated files should be precached
2. Assumes that filename hash is md5+hex

Maybe there are underlying reasons that I'm not aware of, but I think removing those assumptions will make the plugin more flexible.

[jeffposnick]

I'm closing this in favor of adding dontCacheBustURLsMatching support in v5.