Allow to use [contenthash] (of minified JS file) for building the name of an external source map file

Feature request

When storing a source maps in a separate file, it should be possible to use the same filename (despite the file extension) for the source map as is used for the minified JS source file. This does currently not work when the minified source file uses the [contenthash] in its name.

Example:

output: {
  chunkFilename: "[name].[contenthash:8].js",
  filename: "[name].[contenthash:8].js"
},

produces filenames like something.5482zd820.js.

When using [contenthash:8] for the filename of the source map, too, a content hash is included in the generated source map file as well, but of course that is the hash for the source map’s own content and different from the hash of the minified JS file.

What is the expected behavior?

I would like to have something similar to [contenthash] that allows to refer to the minified JS file’s content hash rather than the source map file’s own hash when building its name, so I can get the following:

something.5482zd820.js
something.5482zd820.js.map

(both files using the same hash value here)

What is motivation or use case for adding/changing the behavior?

In my use case I don’t know the “public path” upfront. It is determined at runtime. So I don’t can’t insert a static hint/comment into the minified JS file which directs to browser to the absolute location of the corresponding source map file. Instead, I use the Sourcemap response header when delivering the minified JS files computing the location for the corresponding source map file. This computation (deriving the URL of the source map file form the URL of the minified JS file) is much easier when the source map file has the same filename (despite the extension of coursed) than the minified JS file.

How should this be implemented in your opinion?

Are you willing to work on this yourself? no

[henning-meinhardt]

@alexander-akait I think I just found the solution in @fregante’s comment on issue 7103. Using the following works:

  new webpack.SourceMapDevToolPlugin({
    filename: '[file].map[query]', // Default value
    publicPath: 'etc……',
})

So I’m wondering if [file].map[query]is really the default value here. Leaving it out completely should have produced the same results, right? Anyway, that way it works as expected.

Kind regards Henning

[henning-meinhardt]

@alexander-akait I can’t see the difference from the output section you posted from the the one i’m using. Using that, I get:

file.12345678.js
file.js.map

when having the following applied for source map generation:

plugins: [
	new webpack.SourceMapDevToolPlugin ({
		// filename: "[name].[contenthash:8].js.map",
		append: false
	})
]

When enabling the commented out line, I get the following instead:

file.12345678.js
file.57402411.js.map

because [contenthash] computes to the hash of the source map file.