webpack-md5-hash
webpack-md5-hash copied to clipboard
Manifest chunk hash not updated
If a separate manifest chunk is built with webpack, it's important that the manifest file's chunk hash changes when other content is updated, if one does not rely on inlining the manifest. However, as it is now, the manifest chunk isn't updated when using webpack-md5-hash. Since the hash isn't updated, a user's manifest will reference old chunks.
To reproduce it:
- Pull the following repo: https://github.com/jouni-kantola/webpack-output-by-build-type
- Checkout the branch
manifest-md5-chunk-hash
-
npm run build
- manifest chunk results in:
manifest.d41d8cd98f00b204e980.dev.js
- Update index.js and remove i.e.
console.dir(config);
-
npm run build
- manifest chunk hash still
d41d8cd98f00b204e980
In step 4 and 7 the contents of manifest.d41d8cd98f00b204e980.dev.js
differ, but the files hash is the same.
Step 4, the chunks are referenced like this in the manifest file:
script.src = __webpack_require__.p + "" + chunkId + "." + ({"3":"dev-debug","4":"always-debug","6":"vendor","7":"app"}[chunkId]||chunkId) + "." + {"0":"54ff91330501e270913a","1":"fe3f496e1bee6abf3c8b","2":"52b9240b3a48bd45f6b2","3":"1d340785218727e69e26","4":"47a0bd6038e6bac6aba0","6":"ab3c1652eb7b852b49a5",**"7":"b322ecf5dda7980e9390"**}[chunkId] + ".dev.js";
In step 7 references are:
script.src = __webpack_require__.p + "" + chunkId + "." + ({"3":"dev-debug","4":"always-debug","6":"vendor","7":"app"}[chunkId]||chunkId) + "." + {"0":"54ff91330501e270913a","1":"fe3f496e1bee6abf3c8b","2":"52b9240b3a48bd45f6b2","3":"1d340785218727e69e26","4":"47a0bd6038e6bac6aba0","6":"ab3c1652eb7b852b49a5",**"7":"47159d1b554b86f0584f"**}[chunkId] + ".dev.js";
@jouni-kantola How is the problem now?
I encounter this problem too. Finally,I remove webpack-md5-hash and then everything goes to be OK
@rockybean: It really only becomes a problem if the contents are not inlined.
As the repro branch is still up, I updated to webpack v2.2.1 and went through the steps again. The result is still the same; the manifest js file's hash isn't updated.
@jouni-kantola Try to not use webpack-md5-hash plugin.
Thanks for your consideration, @Rockybean. However, this issue's whole purpose was to address this usecase. So to stop using the plugin is not to fix root cause, only band-aiding the problem.
@jouni-kantola so removing webpack-md5-hash plugin is the only solution?? or you found any alternative for this?
@IamKritika: I recommend to inline the parts that vary into the page. This is one approach for doing that: https://github.com/jouni-kantola/inline-chunk-manifest-html-webpack-plugin
@jouni-kantola when we try to use this plugin, it gives us some compatibility errors.I guess it has to do something with webpack version.
Can we go ahead by just removing md5?
@IamKritika: Yeah, you can leave the chunk hashing to webpack. If you want more info regarding what changes hashes in webpack you can look at (for webpack 2 in particular): https://github.com/webpack/webpack.js.org/issues/652#issuecomment-273023082
Besides not updating the manifest chunk hash when the contents of the manifest change, this plugin also does not update the chunk hash when the global variable name that references the inlined manifest changes.
So when inlining the manifest, and you change the global variable that contains said manifest, your app breaks for users that still have the old manifest cached (since it'll reference the old variable name).
Yeah, you can leave the chunk hashing to webpack.
I assume that that isn't meant to be the resolution to this issue, but just to @IamKritika's usecase right? Because as it is this bug is quite serious in my opinion.
@jouni-kantola
@jouni-kantola Try to not use webpack-md5-hash plugin.
there is other problem when I don't use webpack-md5-hash plugin or webpack-chunk-hash plugin . because if I add a js file or delete a js file, other hash of the assets(js、css、vendors) will be change.
We (my team at work) have also had a problem with this package updating hashing. We have found that the hash will only update consistently if you put this plugin first in the plugins
array in webpack.config.js
(or at least so we think so far).
@DCtheTall Putting this plugin first in line did not resolve the issue for our build. We are omitting this plugin for now.
This plugin is useless because of this major design flaw.