When using new HtmlWebpackPlugin({ filename: 'index-[hash].html', ...}), the hash value seems to be based on the text content of the template file, not on what it produces. This means that changing dependent chunks will not update the output filename, even though the contents have changed. This appears to be the case with both inject: true and explicitly using ejs templating to include <script src="..."></script> tags.
E.g., if I have a template index.html:
<html>
<body>
</body>
</html>
and use a webpack config with:
entry: {index: 'index.js'},
output: {path: 'build/', filename: '[name]-[hash].js'},
plugins: [
new HtmlWebpackPlugin({
filename: 'index-[hash].html',
template: 'index.html',
inject: true,
chunks: ['index'],
}),
]
````
and then get a `build/index-aaaaaaaa.html` of:
```html
<html>
<body>
<script type="text/javascript" src="index-bbbbbbb.js"></script>
</body>
</html>
and then change the javascript for index.js, I'll get a build/index-aaaaaaaa.html (same file name as before) of:
<html>
<body>
<script type="text/javascript" src="index-cccccccc.js"></script>
</body>
</html>
Here is a minimal reproduction.
+1
@jenan-stripe the reason is that it uses the hashing algorithm by webpack - otherwise we would have issues with caching while using the webpack middleware or the webpack dev server
@jantimon Hm does anything else in webpack exhibit this behavior, where the contents may change but the fingerprint does not?
@jenan-stripe I'm running into the same problem with a similar configuration. were you able to get it to work?
@lbalceda Nope. I'm manually fingerprinting in a post-build step.
It makes it very hard to cache the html in a service worker for offline use. This is definitely something that should be fixed.
@jenan-stripe Did u still manually fingerprinting in a post-build step or find a new way to get it work?
@Measy Still manually fingerprinting.
I guess we could add [contenthash] like extract-text-webpack-plugin is doing: https://github.com/webpack-contrib/extract-text-webpack-plugin/blob/8de6558e33487e7606e7cd7cb2adc2cccafef272/src/index.js#L212-L214
Any progress on this ?
This issue had no activity for at least half a year. It's subject to automatic issue closing if there is no activity in the next 15 days.
We should add the [contenthash] solution proposed by matsilver
Fixed with #1021
Most helpful comment
+1