contenthash changing even though file remains identical

Bug report

	output: {
		filename: 'file-[contenthash].js',
		chunkFilename: 'chunk-[contenthash].js'
	},
        optimization: {
        	splitChunks: {
		chunks: 'all',
		cacheGroups: {
				vendors: {
					test: /[\\/]node_modules[\\/]/,
				},
			},
		},
       }

What is the current behavior?

If I have the above config, in my build I get a file called file-XXX.js and chunk-XXX.js. If I change the config line from chunkFilename: 'chunk-[contenthash].js' to chunkFilename: 'CHUNK-[contenthash].js', then the files are file-YYY.js and chunk-XXX.js. So chunk- has the same name but file- has a different name when the chunkFilename changes.

If the current behavior is a bug, please provide the steps to reproduce.

Create a webpack bundle when the chunkFilename is set to one value, then create another bundle after changing the chunkFilename. You’ll see the the contenthash has changed even though the file contents are identical.

What is the expected behavior?

I’m using [contenthash] and in both cases the file contents are identical so the contenthash shouldn’t change and the filename should remain the same.

Other relevant information:
webpack version: 4.17.1
Node.js version: 10.9.0
Operating System: linux
Additional tools:

Author: Fantashit

2 thoughts on “contenthash changing even though file remains identical

  1. I had the same issue with my vendor files from node_modules always generating a new hash, even though I hadn’t changed anything. (webpack 4.26.0)

    I generated 2 builds and diffed the contents. It showed a difference with only one dependency in particular (within the whole vendor file), @uirouter/angularjs.

    The exports provided and harmony reexport/import JS comments were what was showing in different orders each build.

    If anyone know why that might be happening I’m happy to try help fix with some direction.

Comments are closed.

contenthash changing even though file remains identical

This issue was opened because #7984 was closed saying it’s been fixed even though many people have reported that it has definitely not been fixed.

Bug report

	output: {
		filename: 'file-[contenthash].js',
		chunkFilename: 'chunk-[contenthash].js'
	},
        optimization: {
        	splitChunks: {
		chunks: 'all',
		cacheGroups: {
				vendors: {
					test: /[\\/]node_modules[\\/]/,
				},
			},
		},
       }

What is the current behavior?

If I have the above config, in my build I get a file called file-XXX.js and chunk-XXX.js. If I change the config line from chunkFilename: 'chunk-[contenthash].js' to chunkFilename: 'CHUNK-[contenthash].js', then the files are file-YYY.js and chunk-XXX.js. So chunk- has the same name but file- has a different name when the chunkFilename changes.

If the current behavior is a bug, please provide the steps to reproduce.

Create a webpack bundle when the chunkFilename is set to one value, then create another bundle after changing the chunkFilename. You’ll see the the contenthash has changed even though the file contents are identical.

What is the expected behavior?

I’m using [contenthash] and in both cases the file contents are identical so the contenthash shouldn’t change and the filename should remain the same.

Other relevant information:
webpack version: 4.17.1
Node.js version: 10.9.0
Operating System: linux
Additional tools:

Author: Fantashit

3 thoughts on “contenthash changing even though file remains identical

  1. You motivated me to debug this further on my end, and after trying various things to narrow down the cause, it appears that expose-loader is responsible:

    If I have the following rule, building on my Linux vs Mac machines results in a different hash:

    {
      test: require.resolve("jquery"),
      loader: "expose-loader?jQuery!expose-loader?$"
    }

    However, if I change this to the following, the hashes on the two machines then match:

    {
      test: require.resolve("jquery"),
      loader: "expose-loader?$"
    }

    I’ll submit this issue to the expose-loader team.

Comments are closed.