-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hash does not change when only imported modules IDs change #7
Comments
I think this will solve your issue: facebook/create-react-app#210 (comment) E.g. Use HashedModuleIdsPlugin to keep module ids consistent across builds and remove OccurenceOrderPlugin. |
Where to get |
But looks like it doesn't exist in 1.0 :( |
@Poky85 I'm seeing this issue in my own codebase as well, and want to verify what is causing the behavior, so that I can demonstrate that @alexindigo's solution solves this for me. I am attempting to follow the "steps to reproduce" in the issue description, but this phrase is a little tricky to me: "Modules imported in vendor.js are required in app.js". |
@jeromecovington As I understood it, you just have "relations" between chunks. (import gets transpiled into require in the end). Try following, you have your main chunk (and using CommonChunk and OccurenceOrder plugins), so your get async chunks as well, like 1 or 2. Then you add another file to the whole setup, which will be included in the main (app) chunk. (you need to experiment where you require this new file) so it would push up occurence order for files in your async chunks. I hope I made it clear, rather than more confusing :) |
I am also using the |
For me entry point chunk changes the most, but other chunks this is what getting ids update. What you can try, is to find require (import) statement for the modules that end up in async chunk and insert another require before that, so it would change occurrence order for modules in async chunk. Or another way would be to introduce another library in the vendor chunk, that only referenced from within vendor chunk, it won't change content of the main (entry point) chunk, but will change the ids. |
Great, thanks @alexindigo I have been able to reproduce the behavior and will now be on track to verify the solution you published on npm. |
Cool, thanks. Let me know how it's working out for you. |
Yep, @alexindigo seems to be working out well. Thanks for taking the time to publish on npm and answer my questions! |
I have created simple demo to test different hashing algorithms. See webpack/webpack#1856 (comment) |
Hm. I seem to be running into this issue again, using |
Ah, I see you added ids back into the hashing mechanism. I will take the update to your plugin and let you know how it goes, @alexindigo. |
Yep, taking the update seems to have sorted the ids changing, I am getting new chunkhash values now. Thanks. |
Try this:
|
@holyxiaoxin sadly that is not enough. When you change a file name you also need to change any reference to the file. The correct order to do this in to avoid wrong file caching is to traverse the dependency graph in a depth first post order traversal, where you move the file and update any reference to the file. This ensures that when a file changes its content, any file pointing to it will also be cache-busted with new content, because it contains the new name of the dependency Any other consistent hashing algorithm is flawed, which is also why all other projects that try to solve this without employing a dependency graph have so many bugs, most of which they can't fix because of their architecture |
@Munter I might argue that the current hashing algorithm is too strict because of hash base on file path too. If you have 2 similar content in different locations, and would like them to have the same hash, you would have a problem. I would probably just write a simple plugin to do a system hash on the file content itself, maybe the name too(but it's not important for me). |
@alexindigo Good day,sorry but i can't find how to post issue in your repo - |
@matpaul Thanks for point it out. Looks like issues are off by default for forked projects. I tuned it on. As for the question. Do you mind to provide a bit of code to experiment with it. Without looking at the code/config, I can assume that there are some parts that aren't exposed to the plugins. But I'd like to see more, to understand the problem. Thanks. |
To generate stable module ids For webpack 1.x version, we can use this plugin https://github.com/webpack/webpack/blob/master/lib/HashedModuleIdsPlugin.js |
Webpack references modules with number IDs. Seems that when only module IDs change then bundle's MD5 hash does not change. Look at example. Two builds of the same Webpack chunk. The only difference are IDs of imported modules. Despite this the hashes are same.
https://gist.github.com/Poky85/d8fe2d4711d532fbb3ea25a5efbbf992
https://gist.github.com/Poky85/e441799fdf314684d3eb41744a2ba4c6
Steps to reproduce:
webpack.config:
`
var webpack = require("webpack");
var WebpackMd5HashPlugin = require('webpack-md5-hash');
var config = {
};
module.exports = config;
`
The text was updated successfully, but these errors were encountered: