[hash] placeholder doesn't match with all generated hashes

[MatteoGabriele]

Do you want to request a feature or report a bug?
bug

What is the current behavior?
I use an hashed name for the build folder which contains js chunks, extracted css files and main application bundle.

Everywhere, the placeholder [hash:8] that I'm using, returns the same string, which allows me to put javascript and css in the same generated folder: except the file-loader hash.

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

webpack bundle output

 ...
  output: {
    path: `${paths.appBuild}`,
    publicPath: '/',
    chunkFilename: `[hash:8]/chunks/[chunkhash:8].js`,
    filename: `[hash:8]/[name].js`
  },
 ...

ExtractTextPlugin

...
new ExtractTextPlugin({
    filename: `[hash:8]/[name].css`,
    ignoreOrder: true,
    allChunks: true
}),
...

file-loader

...
test: /\.(ico|jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2)(\?.*)?$/,
  loader: 'file-loader',
  options: {
    name: '[hash:8]/asset/[name].[ext]'
  }
...

What is the expected behavior?
The hash should be always the same like ExtractTextPlugin does

Please mention other relevant information such as your webpack version, Node.js version and Operating System.

OS: macOS Sierra
Node: v7.4.0
Webpack: v2.2.1

[fmakdemir]

@MatteoGabriele it writes that hash is the hash of file contents (defaults to hex-md5). Thus I believe this is intentional and I would like to have build hash included as well.

[MatteoGabriele]

@fmakdemir yeah I see what you mean. They probably have to provide two different placeholders

[alexander-akait]

@MatteoGabriele we use https://github.com/webpack/loader-utils#interpolatename for placeholders. Can your provide example what your expected using [hash:8]/asset/[name].[ext] and what your actually get.

[fmakdemir]

@evilebottnawi We were expecting getting build hash webpack instead of file hash.
So with [hash:8]/asset/[name].[ext] and if build hash was starting with ea382a24 then all files entrypoint files should be generated under ea382a24/asset folder with name resolved by [name].[ext]
So for this we need another placeholder holding build hash/id of current build.

[MatteoGabriele]

I've added a repo that explains the issue:
https://github.com/MatteoGabriele/file-loader-hash-issue

Every webpack plugin uses the same hash, besides file-loader.
In the example the folder in the /dist is generated with an hash, and both app.js and /assets folder should be in the same folder but they end in 2 separate folders.

from my prospective they both should use the same hash

hope it's clear enough :)

thanks!

[alexander-akait]

@MatteoGabriele @fmakdemir Why do your not use https://github.com/webpack/docs/wiki/configuration#outputpath with hash?

[MatteoGabriele]

@evilebottnawi well it could solve quite the issue, but not really. Like this is true that you only need to hash in one single place, which is nicer, but then the entire build is a hashed folder.

For example, I need a build that has a static folder, an index.html file and the hashed build with all the assets, js and css in it.

I could achieve that moving files after the compilation but I don't know; seems like this solution is just moving the issue somewhere else. I still think that this loader should behave exactly like the majority of Webpack loaders: serving a common hash string across the application.

if you think this ticket is fixed, you can close it. But I do think that this is still a valid issue.

thanks for your time

[fmakdemir]

@evilebottnawi because I can't put build hash in filename with it.
The solution you proposed can only change output folder name not filename

[alexander-akait]

@MatteoGabriele @fmakdemir

I still think that this loader should behave exactly like the majority of Webpack loaders

https://github.com/webpack/loader-utils#interpolatename according to the documentation hash is the hash of options.content, can your provide example where it is working other?

[MatteoGabriele]

@evilebottnawi
I have updated the same example
It now also handles also CSS and via extract-text-webpack-plugin I'm able to just pass an hash to the file name, and will go in the same folder of the javascript file. The svg instead will still land on another folder because of the hash issue

thanks for your time

[alexander-akait]

@MatteoGabriele related issue #177 (just information)

[bjunc]

Might not be exactly the same setup, but I was able to accomplish a workaround by using the publicPath file-loader param (eg: loader: 'file-loader?publicPath=../&name=/asset/[name].[ext]') and assigning the [hash:8] to the output.publicPath.

This basically circumvents file-loader's version of [hash:8] by making the reference a relative path, whereby the CSS uses the intended [hash:8] and the loaded files (fonts, images, etc.) are relative to the CSS (rather than receiving their own hash).