webpack: chunkhash does not change when module ids do
I have been unable to create a simple repro of this issue, but I’m hoping by describing it, people may have an idea of what’s going on. This sounds similar to #1155.
We have two entries, one that just requires some images using url-loader (entry A), and another includes our javascript app (entry B).
After making some changes that should only effect entry B, we built everything, and found that entry A had the same file name (same chunkhash) as before, even though module ids had changed. For example, before:
!function(e){function c(r){if(n[r])return n[r].exports;var a=n[r]={exports:{},id:r,loaded:!1};return e[r].call(a.exports,a,a.exports,c),a.loaded=!0,a.exports}var n={};return c.m=e,c.c=n,c.p="",c(0)}({0:function(e,c,n){"use strict";n(652),n(650),n(649)},649:function(e,c,n){e.exports=n.p+"images/favicon.d6a3e4a5239105abdca2874ee0b29e87.png"},650:function(e,c,n){e.exports=n.p+"images/icons/image1.94cd651e18cc108dbcac932ca11f87e0.svg"},652:function(e,c,n){e.exports=n.p+"images/image2.3d0c754f88b3aa29f88f1422f158649d.png"}});
after:
!function(e){function c(r){if(n[r])return n[r].exports;var a=n[r]={exports:{},id:r,loaded:!1};return e[r].call(a.exports,a,a.exports,c),a.loaded=!0,a.exports}var n={};return c.m=e,c.c=n,c.p="",c(0)}({0:function(e,c,n){"use strict";n(653),n(651),n(650)},650:function(e,c,n){e.exports=n.p+"images/favicon.d6a3e4a5239105abdca2874ee0b29e87.png"},651:function(e,c,n){e.exports=n.p+"images/icons/image1.94cd651e18cc108dbcac932ca11f87e0.svg"},653:function(e,c,n){e.exports=n.p+"images/image2.3d0c754f88b3aa29f88f1422f158649d.png"}});
Just fyi, plugins we’re using:
CommonsChunkPlugin
UglifyJsPlugin
DedupePlugin
OccurenceOrderPlugin(true)
Assuming this (https://webpack.github.io/docs/plugins.html) specifies the order of steps, hashing occurs between before-hash and after-hash while I’m assuming module ids are last changed at after-optimize-module-ids (which occurs before the hash). UglifyJsPlugin is happening at optimize-chunk-assets, although as this happens after the chunkhash is calculated, it shouldn’t matter here.
My guess is that chunkhash is calculated solely on content, but this is an issue if its intended to be used for long term caching. If anyone can point to where this is happening, I don’t mind taking a look.
I’ll continue to try to find a simple repro. I should note that this isn’t probably isn’t specific to my setup above, and just presented itself that way.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 8
- Comments: 47 (6 by maintainers)
Seeing same issue. Different ids, everything else is the same including
chunkhash.Using
[chunkhash]for the filename andnew WebpackMd5Hash()in the plugins section.PS. Interesting that it still has comments in the minified version.
Thanks. We’re yet to adopt recordPath, but thinking about it. What’s your take on checking in records file?
And we do use Dedupe, not to solve any specific problem, but as insurance for the future.
@Poky85 I’ll borrow few things from your config, thanks. 😃
Save the used module IDs with the
recordsPathoption. This makes webpack always pick the same ID for the same module, as recorded in the records file.Summarized test using https://github.com/Poky85/webpack-chunkhash-demo
https://www.icloud.com/numbers/0cEAfcZiNPPwfzGMm4_n160NQ#webpack-chunkhash-demo-resuts
Would be nice to make test automatized 😃
@alexindigo There is no difference if I use webpack-chunk-hash (I tried with webpack 2). The hashes are similar for both cases (4f9600f39d39d961f16d).
This exactly what brought me in tis whole webpack hashing thingy. Seems like it’s doing of OrderOccurence plugin, and also md5-hash us mutating modules array, which added more noise.
But despite those things, it’s hard problem in general, if you replace named references with numbers, then you have modules like 1, 2, 3, 4, 5 and when you add one more module it will affect some of the modules (unless you keep some kind of state between builds).
And when I played with NamedChunk plugin, I found that it’s just creating extra mapping, but ids still exist internally, so the problem doesn’t go away completely. But this is webpack’s design.
@sokra is there a way to get rid of module ids and just use their names/paths (similar to what requirejs does)?
@alexindigo Btw in my app I have interesting problem. Sometimes same chunk differs between 2 builds although source code is same. I found that Webpack changes module IDs between those 2 builds (in my case all IDs are increased by 1 although nothing changed, I just run build twice – same machine, same node_modules, same directory, same webpack config…
This is screenshot of module source used for hashing in your
webpack-chunk-hashplugin (with some extra console.log 😃)Pretty sure I have seen this is issue somewhere…
@Poky85 Cool. Thanks for all your work.
Meanwhile, I’m working on integrating your tests into automatic tests in webpack-chunk-hash.
@alexindigo Now
webpack-chunk-hash@0.3.0pass all tests in my demo.Definitely hashing plugin should consider compiled version of chunk for hashing. Because in case you have 2 or more chunks that contain same modules then module IDs can change on every build resulting in different chunk even if source code didn’t change.
I will test your plugin in real world application and will thinking about more test cases (for example I have experienced that some node_module(s) breaks hashing etc.)
I updated my demo https://github.com/Poky85/webpack-chunkhash-demo so we can easily test different Webpack configurations.