Added in f28f53a

This solution is not good. Please reconsider. Hash should be not from content, but from relative path. Squirrel delta updates, AppImage delta updates, Appx block map, and planned Nsis block map updates work correctly only and only if file names are not changed. Otherwise delta file / block map diff will be huge for minor change.

Yes — electron builder uses ASAR by default, but in any case better to use another solution.

This brings up a good point. Would adding a query hash be a better solution?

Instead of [name].[hash:7].[ext] it could be [name].[ext]?[hash:7]. This should eliminate having to update each individual asset in builds, and will force the browser to ignore cache.

@SimulatedGREG Query is not a solution, because to solve this issue we need to emit files with different names.

@chenweiqun Do you mean that such files located in the some external node module? Because if you will put files to static, it will be processed as is and not copied to img. Could you please provide name of this module to test?

Looking at the file-loader documentation, the [path] placeholder will work much better. It unfortunately doesn't always produce nice and short filenames, but does solve the problem of overwritten assets and will not add to update deltas unintentionally.

Hash: 1f29967d01d8a29a16de                                                           
Version: webpack 2.7.0
Time: 9768ms
                              Asset       Size  Chunks             Chunk Names
imgs/src/renderer/assets/a/logo.png    61.9 kB          [emitted]  
imgs/src/renderer/assets/b/logo.png     124 kB          [emitted]  
                        renderer.js     100 kB       0  [emitted]  renderer
                         styles.css    1.25 kB       0  [emitted]  renderer
                         index.html  352 bytes          [emitted]  

@SimulatedGREG I still don't understand the issue. I tried to write unit test, but not luck.

In your example now I see that such assets placed in the src/renderer/assets.

The question is — why? Why these assets not placed into the static directory? Should we support such use case? Your change impacts other users, and it is questionable for me, because it is clearly stated, that static files should be in the static, and src for text source files.

unfortunately doesn't always produce nice and short filenames

If you say that yes, we should support such use case, we can easily send PR to file-loader to use hash of path, instead of hash of content.

The problem that @chenweiqun originally mentioned would produce the following output, which contains only 1 logo.png instead of 2 different logo.pngs.

Hash: 1f29967d01d8a29a16de                                                           
Version: webpack 2.7.0
Time: 9768ms
                              Asset       Size  Chunks             Chunk Names
                      imgs/logo.png    61.9 kB          [emitted]  
                        renderer.js     100 kB       0  [emitted]  renderer
                         styles.css    1.25 kB       0  [emitted]  renderer
                         index.html  352 bytes          [emitted]  

Because both a/logo.png and b/logo.png have the same filename, only the latter is produced since a/logo.png gets overwritten by b/logo.png. Applying the [path] can ensure both assets are properly produced. It would be worth creating a PR to file-loader to create another hashing option based on the file path.

Should we support such use case? Your change impacts other users, and it is questionable for me, because it is clearly stated, that static files should be in the static, and src for text source files.

This is more of a webpack situation, as it is able to step into all component file imports and pass them through to url-loader/file-loader. Importing assets inside components through vue-loader and/or accessing them directly from static/ is a vuejs-templates/webpack implementation that has been adopted by many users. Supporting both is necessary for certain frameworks that can internally require their own assets, therefore allowing webpack to further optimize outputs when possible. electron-vue mirrors that approach already, so the above change does not impact users. In the end, src is not just for text files.

Okay, turns out file-loader is passing the name option directly into loader-utils#interpolateName . Luckily with the latest version of that, there is a [folder] placeholder that we can use instead to create a much smaller output name.

  Hash: d76a8a9a6ee95013e16c
  Version: webpack 3.5.5
  Time: 1096ms
                                 Asset       Size  Chunks                    Chunk Names
                       imgs/a/logo.png    61.9 kB          [emitted]         
                       imgs/b/logo.png    61.9 kB          [emitted]         
                           renderer.js    1.09 MB       0  [emitted]  [big]  renderer
                            index.html  420 bytes          [emitted]         

The same fix applied to electron-webpack, thanks for clear explanation and good fix.