I'm getting the following error when I run webpack-dev-server --hot.
ERROR in chunk vendor [entry]
[name].[chunkhash].js
Cannot use [chunkhash] for chunk in '[name].[chunkhash].js' (use [hash] instead)
I do not get this error if I run webpack-dev-server without the --hot flag, or if I just run webpack to build the files.
This is my config file:
var baseConfig = {
resolve: {
root: [__dirname],
},
entry: {
app: [
'showroom/app.js',
'showroom/index.html',
],
vendor: [
'react',
'react-dom',
'babel-polyfill',
],
},
output: {
filename: '[name].[chunkhash].js',
chunkFilename: '[name].[chunkhash].js',
path: 'dist',
},
module: {
loaders: [
{
test: /\.jsx?$/,
exclude: /(node_modules|dist)/,
loader: 'babel-loader',
query: {
plugins: ['transform-runtime'],
presets: ['es2015', 'react'],
}
},
{
test: /\.html$/,
loader: 'file?name=[name].[ext]',
},
{
test: /\.less$/,
loader: 'style!css!less'
},
],
},
plugins: [
// Without these 2 plugins the vendor hash changes every time the app
// changes, even though there are no changes to the vendor.
// https://github.com/webpack/webpack/issues/1315
new WebpackMd5Hash(),
new webpack.NamedModulesPlugin(),
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor',
filename: '[name].[chunkhash].js',
minChunks: Infinity,
}),
new HtmlWebpackPlugin({
template: 'showroom/index.html',
filename: 'index.html',
minify: {
removeComments: true,
collapseWhitespace: true,
},
}),
]
};
Is this expected behaviour, or a bug?
If it's not expected behaviour, I'd be happy to strip down this config file and create a minimal github repo that reproduces this bug.
Also - I wasn't sure whether to report this in webpack-dev-server or in webpack.
Thanks!
Just came across this myself - curious to know if it's expected behaviour or not...
Got this weird issue too. BTW, @andreisoare 'babel-polyfill' and NamedModulesPlugin significantly increase the bundle size. And I think you can remove 'babel-polyfill' since you use 'transform-runtime'.
Appears to be expected behavior: https://github.com/webpack/webpack/issues/2393#issuecomment-216614060
Closing this, because you should not use [chunkhash] or [hash] for development. This will cause many other issues, like a memory leak, because the dev server does not know when to clean up the old files.
I am working on documenting this, because this has caused many issues.
Shouldn't this decision be left to the developer to decide?
It's possible that webpack will create new files, but plugin's exist to clean up those old files. https://github.com/gpbl/webpack-cleanup-plugin for example.
I'm fairly new to web development and webpack, but wouldn't cache-busting still be useful for development?
I'm fairly new to web development and webpack, but wouldn't cache-busting still be useful for development?
No, you should have every caching feature off in dev. There's no real benefit; you're working on localhost anyway, so downloading is only limited by your imagination disk. Of course you can use a cleanup plugin and then still use it, this package doesn't forbid you to use that, but it's not recommended and can cause the process to crash due to memory issues.
The issue is closed, but no any solution has been provided. How do you solve the problem?
So far I have come up with the following code in my webpack config:
filename: `[name]${isDev ? '' : '[chunkhash:8]'}.js`,
Does any of you know better solution?
@just-boris, jup, that's the solution I use in all my projects too. It's not very clean but works perfectly.
@SpaceK33z looking at adopting this pattern for our own project but I have a question: if the bundle no longer has a hash in the name, how do we prevent the browser from caching a stale version of the bundle from a previous run?
@SpaceK33z Hi, have you landed the mentioned documentation for this issue somewhere?
Refs https://github.com/webpack/webpack/issues/1363#issuecomment-135010251
Closing this, because you should not use [chunkhash] or [hash] for development. This will cause many other issues, like a memory leak, because the dev server does not know when to clean up the old files.
:+1: Make sense :)
Folks, I'm interested about memory leak when hash is used. Memory leak in what? Is there any bug ticket related to the memory leak when hash is used? I'd like to read more about it. Thank you.
This is a zombie issue (lol), it just won't die! I thought this issue was solved when @just-boris posted the following, which certainly voiced my frustration that no one was posting a solution to the issue:
The issue is closed, but no any solution has been provided. How do you solve the problem?
So far I have come up with the following code in my webpack config:
filename: `[name]${isDev ? '' : '[chunkhash:8]'}.js`,
I am migrating websites to Webpack 4 this weekend, and my issue is that the concept of "environment" in Webpack has changed in v4. There is no longer a value for process.env.NODE_ENV upon which to create an isDev boolean to use in @just-boris code above. We are now being told to use --mode development in the command line.
For those in the same boat I offer my current solution, albeit hacky. After dumping process.env to the console and sifting the entrails, this code is working for me to provide the v4 environment boolean:
let isDev = (process.env.npm_lifecycle_script.indexOf('development') === -1) ? false : true;
I understand this is closed. But I would like to add a scenario that it would have been helpful if we could disable cache for dev server.
I am developing a Atalssian plugin, during local/integration test, I expose my local server to the internet with Ngrok (or something similar). If the file is cached, I will not be able to test it.
Most helpful comment
Closing this, because you should not use
[chunkhash]or[hash]for development. This will cause many other issues, like a memory leak, because the dev server does not know when to clean up the old files.I am working on documenting this, because this has caused many issues.