Skip to content
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

Open
Poky85 opened this issue Sep 22, 2016 · 22 comments
Open

Hash does not change when only imported modules IDs change #7

Poky85 opened this issue Sep 22, 2016 · 22 comments

Comments

@Poky85
Copy link

Poky85 commented Sep 22, 2016

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 = {

entry: {
    "bundle/app": ["./src/app.js"],
    "bundle/vendor": ["./src/vendor.js"]
},

output: {
    path: "./www/assets",
    publicPath: "/assets/",
    filename: "[name].[chunkhash].js",
    chunkFilename: "[name].[chunkhash].js"
},

plugins: [
    new WebpackMd5HashPlugin(),
    new webpack.optimize.OccurenceOrderPlugin(),
    new webpack.optimize.CommonsChunkPlugin({
        name: "bundle/vendor"
    })
],
bail: true

};

module.exports = config;
`

@Jyrno42
Copy link

Jyrno42 commented Sep 27, 2016

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.

@jampy
Copy link

jampy commented Nov 8, 2016

Where to get HashedModuleIdsPlugin from? Currently published Webpack version 1.13.3 doesn't seem to include it.

@alexindigo
Copy link

But looks like it doesn't exist in 1.0 :(

@jeromecovington
Copy link

jeromecovington commented Nov 9, 2016

@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". import and require seem to be nearly synonymous actions, so I'm not seeing how to make a change to my bundle code to reproduce a changed module id. Perhaps a sample of changed code that results in the changed module ids would help?

@alexindigo
Copy link

@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 :)

@jeromecovington
Copy link

I am also using the CommonsChunkPlugin, so any shared import-ed modules end up getting bundled as require statements in the common bundle. And any resulting additional require statements in common do seem to cause a chunkhash update there. However, I have seen changes in an entry point bundle (not common) related only to updated module ids not resulting in a chunkhash change for said entry point bundle. I'm having a hard time reproducing this behavior, but I know it has been a problem for me.

@alexindigo
Copy link

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.

@jeromecovington
Copy link

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.

@alexindigo
Copy link

Cool, thanks. Let me know how it's working out for you.

@jeromecovington
Copy link

Yep, @alexindigo seems to be working out well. Thanks for taking the time to publish on npm and answer my questions!

@Poky85
Copy link
Author

Poky85 commented Nov 12, 2016

I have created simple demo to test different hashing algorithms. See webpack/webpack#1856 (comment)

@jeromecovington
Copy link

jeromecovington commented Nov 30, 2016

Hm. I seem to be running into this issue again, using webpack-chunk-hash where it seems that the chunkhash digest is being produced prior to the module id insertion. In this case, I have an entry point where the ids are less by one (due to the removal of a module), yet its chunkhash is identical to the one produced for the entry point prior to the removal of the module. The change is not evident across multiple entry points, or in the common file, as the module removal affects only the single entry point in question. @alexindigo I was going to add this as an issue to https://github.com/alexindigo/webpack-chunk-hash but I don't see any place to add issues there?

@jeromecovington
Copy link

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.

@jeromecovington
Copy link

Yep, taking the update seems to have sorted the ids changing, I am getting new chunkhash values now. Thanks.

@holyxiaoxin
Copy link

Try this:

const spawn = require( 'child_process' ).spawnSync
const ls = spawn( 'git', [ 'rev-parse', 'HEAD' ] );
const hashFromGitCommit = ls.stdout.toString().trim();

filename: `[name].${hashFromGitCommit}.js`,

@Munter
Copy link

Munter commented Jan 9, 2017

@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

@holyxiaoxin
Copy link

@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).

@matpaul
Copy link

matpaul commented Feb 13, 2017

@alexindigo Good day,sorry but i can't find how to post issue in your repo -
So l use your plugin webpack-chunk-hash, also use HashNameslds and everything is ok but today i found issue when chunk ids changed hash not change(
l mean webpackJsonp([10,9]... change to webpackJsonp([11,8] and hash was the same(
Do you know how to fix this issue?

@alexindigo
Copy link

@matpaul Thanks for point it out. Looks like issues are off by default for forked projects. I tuned it on.
Please feel free to create issues here: https://github.com/alexindigo/webpack-chunk-hash/issues

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.

@Thinking80s
Copy link

Thinking80s commented Mar 6, 2017

https://sebastianblade.com/using-webpack-to-achieve-long-term-cache/

@whq731
Copy link

whq731 commented Mar 9, 2017

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
which has included in webpack 2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants