size path matching should have option to exclude generated-hashes

[jakebolam]

size path matching should have option to exclude generated-hashes

• Flag when a hash changes? i.e. invalidating cache

[tinovyatkin]

Or generated paths, otherwise comparing feature makes no sense:

[rtymchyk]

I imagine anyone running webpack for production builds will be using content hashes to maintain proper cache busting, which makes this tool largely useless until we have something in place to handle that.

Thoughts on on exposing a normalizeFilename in options so provide fine grained control in dealing with file names?

[gex]

i think this tool should run on your ci server and in that environment you can set a filename without any hash. this way you'll have the same filename all the time.

for example i use heroku ci in a project and in my webpack.config.js i set the filename like this:

output: {
  filename: process.env.CI === 'true' ? 'bundle.js' : 'bundle.[hash].js',
  publicPath: '/'
}

[rtymchyk]

@gex You're completely right. I still personally would like to use the same config for CI as I do for production to maintain parity, but this is a good work-around.

[roopakv]

+1 to this issue. While we can modify something specific for our CI, would be much easier if this were simply supported. We have quite a complex build system and accounting for one more if condition to remove the hash isnt necessarily the easiest thing to do for us.

If folks are open to it, I wouldnt mind giving this issue a shot

[dte]

@roopakv I took a first stab here https://github.com/dte/bundlewatch/pull/1 (WIP)

[cheapsteak]

Made another attempt here #192 that addresses comments in https://github.com/dte/bundlewatch/pull/1

[ChromeQ]

i think this tool should run on your ci server and in that environment you can set a filename without any hash. this way you'll have the same filename all the time.

I understand the approach here, but doesn't this mean running a build twice on the CI server? Once without the hashes (for bundlewatch to report nicely) and again to create the artifacts which my CI is actually responsible for building for deployment (which requires hashing filenames)

[cheapsteak]

Is there anything we can do to help move #192 along faster?

We would like to be able to deploy build artifacts from CI, and the current workaround of not generating hashes for CI build artifacts will no longer be a workable solution

[cheapsteak]

hmm
this is weird,

https://ja2r7.app.goo.gl/PJJq6ibYj5AvUydMA

I'm seeing the same issue as before, we're seeing additions and removals as separate things in the comparison report (but the file names no longer include hashes)

did I misconfigure the fix somehow or is anyone else seeing similar things?