removeKeyHash doesn't work with compression-webpack-plugin

[jkevingutierrez]

• Manifest Plugin Version: 2.2.0
• Webpack Version: 4.44.2
• Operating System (or Browser): macOS 10.5.7
• Node Version: 12.8.3
• Link to reproduction (⚠️ read below): https://repl.it/@jkevingutierrez/manifest-plugin-repro-3#webpack.config.js

Expected Behavior

Using compression-webpack-plugin with webpack-manifest-plugin and setting the option removeKeyHash as true should remove hashes from files generated by the compression plugin.

{
  "input.js": "input.00a4d7023f1cc4cf6c59.js",
  "input.js.gz": "input.00a4d7023f1cc4cf6c59.js.gz"
}

Actual Behavior

Files generated by compression-webpack-plugin have hashes in the name of the file:

{
  "input.js": "input.00a4d7023f1cc4cf6c59.js",
  "input.00a4d7023f1cc4cf6c59.js.gz": "input.00a4d7023f1cc4cf6c59.js.gz"
}

Additional Information

As per #231 I wasn't able to test it in Manifest version 3.

Also, adding a map like

map: (file) => {
  file.name = file.name.replace(/(\.[a-f0-9]{20})(\..*)$/, '$2');
  return file;
},

Fixes the issue, but it would be great if it would be done automatically without having to add a map function.

It would also be great if it could be done automatically independent of the hash size. It should work for

filename: '[name].[hash].js' and also for filename: '[name].[hash:8].js'

[shellscape]

I'm stretched a little thin at the moment so would appreciate a PR to resolve this.

[achan-godaddy]

not sure if it's related directly to the compression-webpack-plugin because I also saw this with just webpack 5 and [contenthash] being the 20 hash length

removeKeyHash: /([a-f0-9]{20,32}\.?)/gi,

solved it for me in what I think should be a backwards compatible way for a range of 20-32 char hashes. I don't know enough about the hash lengths to say what the minimum should be, but this at least works so if we're happy with that I could try to submit a pr.

[cascornelissen]

svg-spritemap-webpack-plugin uses a default hash length of 16 characters. I can imagine the hash has to be a certain length to avoid collisions but an exact length of 32 characters seems somewhat arbitrary to me? I'd vote for {12,32} or {16,32} to at least solve most issues with existing plugins.

I'm willing to submit a PR @shellscape, but I first want to ensure that you agree with this opinion.

[shellscape]

@cascornelissen sounds reasonable to me. will this introduce any breaking changes?

[cascornelissen]

It could, in theory, but that applies to the arbitrary length of 32 as well because any string could match with the regex (as long as it's within the a-z0-9 range). That's why I can imagine there should be a minimum length but I'd guess 16 is safe.

[stale]

Hey folks. This issue hasn't received any traction for 60 days, so we're going to close this for housekeeping. If this is still an ongoing issue, please do consider contributing a Pull Request to resolve it. Further discussion is always welcome even with the issue closed. If anything actionable is posted in the comments, we'll consider reopening it. ⓘ