You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When emitting files from e.g. file-loader that generate files with the same path, only one key is included in the manifest, when I would expect all keys to be included pointing to the same filename.
E.g. a contrived example: if setting file-loader's name option to a static value such as foo.png, I would expect the manifest.json to look something like:
Notice how the values other than cat.jpg have been lost. This means that server code expecting to reference some_image.png or animation.gif will have no way to know that they are supposed to map to foo.png.
Again, this is a contrived example since you'd never hardcode an image name like this, but in a more complex example this would occur if two different paths map to the same file with a different name, and we output [contenthash].[ext] or equivalent.
Technical details
Because internally the asset mapping is stored in this.assetNames as a map of hashed filename: original filename, if two assets are output with the same hashed filename, only the first one will be included in the manifest.
It seems like there are two ways this could be solved:
switch the order of this.assetNames to use the originalName as the key, mapping to the name from the loader (this matches more closely the final output of the manifest, anyway)
keep the structure, but change the this.assetNames values to be an array of original filenames rather than a single one. Less surface area, but would allow multiple manifest keys to map to the same manifest values
My preference would be for the first option since it maps more closely to how I think about this plugin conceptually - using the original, unhashed filenames as our keys, and having our hashed output filenames as the values. Curious if there was a reason I'm missing for having things be the other way round?
Webpack version
4.31.0, node v8.15.1
Webpack config
Using the config in the mocha tests in the repo.
Operating system
Ubuntu 16.04.4 LTS
The text was updated successfully, but these errors were encountered:
The problem
When emitting files from e.g. file-loader that generate files with the same path, only one key is included in the manifest, when I would expect all keys to be included pointing to the same filename.
E.g. a contrived example: if setting file-loader's
name
option to a static value such asfoo.png
, I would expect the manifest.json to look something like:when in reality, it looks more like:
Notice how the values other than
cat.jpg
have been lost. This means that server code expecting to referencesome_image.png
oranimation.gif
will have no way to know that they are supposed to map tofoo.png
.Again, this is a contrived example since you'd never hardcode an image name like this, but in a more complex example this would occur if two different paths map to the same file with a different name, and we output
[contenthash].[ext]
or equivalent.Technical details
Because internally the asset mapping is stored in
this.assetNames
as a map of hashed filename: original filename, if two assets are output with the same hashed filename, only the first one will be included in the manifest.It seems like there are two ways this could be solved:
this.assetNames
to use theoriginalName
as the key, mapping to thename
from the loader (this matches more closely the final output of the manifest, anyway)this.assetNames
values to be an array of original filenames rather than a single one. Less surface area, but would allow multiple manifest keys to map to the same manifest valuesMy preference would be for the first option since it maps more closely to how I think about this plugin conceptually - using the original, unhashed filenames as our keys, and having our hashed output filenames as the values. Curious if there was a reason I'm missing for having things be the other way round?
Webpack version
4.31.0, node v8.15.1
Webpack config
Using the config in the mocha tests in the repo.
Operating system
Ubuntu 16.04.4 LTS
The text was updated successfully, but these errors were encountered: