webpack-dev-middleware
webpack-dev-middleware copied to clipboard
`output.clean : true` is not working with dev server
Bug report
What is the current behavior?
output.clean: true is not working with webpack dev server, when building for the first time, or when project is rebuilding due to sources change.
Description
I was trying to configure webpack to clean the dis folder for one of my projects, and decided to use brand new output.clean configuration as I'm using "webpack": "^5.21.2" and this config is supported starting from version 5.20
Config works fine in production build, but when I start webpack dev server with writeToDisk: true webpack doesn't clean the dist/ directory neither upon the start of the dev server nor upon project rebuild.
Initially I though that it might be not supposed to work with dev server, but changing
output: {
...
clean: true
},
to
output: {
...
clean: {
dry: true,
}
},
does log what files it should delete when rebuilding project:

If the current behavior is a bug, please provide the steps to reproduce.
- clone my sandbox created for debugging this issue https://github.com/vovkvlad/webpack_clean-test
- run
npm iin the root of the repository - run
npm startto start the application - go to
src/App.jsand make any change so that webpack catch it up and rebuild the project
Expected behavior:
old files from dist/ folder should me removed, and dist/ folder should contain one instance of each bundled file
Current behavior:
dist/ folder is not being cleaned, and contains several files for each bundled files:

What is the expected behavior?
old files from dist/ folder should me removed, and dist/ folder should contain one instance of each bundled file
Other relevant information:
webpack version: webpack 5.27.1
Node.js version: v14.15.0
Operating System: macOs Catalina Version 10.15.7
Additional tools:
This issue was moved from webpack/webpack#12949 by @alexander-akait. Original issue was by @vovkvlad.
I have ideas how we can fix it, but need more time, idea:
compiler.outputFileSystem = new CombinedFileSystem(memoryFileSystem, realFileSystem)
so we will have layer layered file system (memory + real fs)
I can reproduce the problem with Webpack 5.36.
output: {
clean: true,
},
devServer: {
writeToDisk: true,
},
I can reproduce that too with webpack 5.36.2 and webpack-dev-server 3.11.2 and the configuration:
output: {
clean: true,
},
devServer: {
writeToDisk: true,
}
Any updates on this? Still an issue with webpack 5.51.1 and webpack-dev-middleware 5.0.0.
No, it will be fixed in near future, we need layer fs
the output.clean release at webpack v5.20.0 and the issue already exists.
Same problem on webpack 5.65.0 and webpack-dev-server 4.6.0
Yoooo, still nothing? xD
I just keep using clean-webpack-plugin then.
:(
Still a bug as of webpack 5.71.0 and webpack-dev-server 4.7.4
No, it will be fixed in near future, we need layer fs
9 months later and still nothing. Is this "near future"?
Still happening with webpack 5.72.0 and webpack-dev-server 4.9.0.
Still happening for me with webpack 5.73.0 and webpack-dev-server 4.9.2.
Hello :)
Just to let you know that I have the same issue with clean: true, but with webpack-hot-middleware which doesn't use webpack-dev-server but only webpack-dev-middleware.
When I use webpack from cli, it works.
When I use the process as a middleware, it works for my asset/resource type in module, but it doesn't for the js files from the output configuration, these files are generated again each time without deletion.
Clean Webpack Plugin works fine from cli & from middleware.
webpack : 5.74.0 webpack-dev-middleware : 5.3.3 webpack-hot-middleware : 2.25.0
Still happens with me as well
Interesting note, I've been using Clean Webpack Plugin while waiting for a solution here, but noticed that after initial bundling, an asset is still available on the localhost even though it's not shown in the file tree. I can still access that asset directly by visiting the link to it in the browser. This was resolved when I set the output.clean: true in my webpack config.
Still an issue with webpack 5.74.0 and webpack-dev-server 4.11.1.
Clean Webpack Plugin isn't working for me either.
I'm not sure if it's because my path is not a static path, as it is based on a version number from the previous git commit, so I have multiple build/app/:version folders that never get cleared? So the more commits I make the more folders I have.
const VERSION = childProcess.execSync('git rev-parse --short HEAD').toString().trim();
const ASSET_PATH = `/app/${VERSION}/`;
return {
...
plugins: [
new CleanWebpackPlugin(),
],
output: {
publicPath: ASSET_PATH,
filename: '[name].[fullhash].js',
chunkFilename: '[name].[hash].[chunkhash].chunk.js',
path: path.resolve(__dirname, `build/${ASSET_PATH}`),
clean: true,
},
};
Sorry for delay, I am looking for a solution before the next webpack-dev-server release (with the latest version of webpack-dev-server)
@AaronMcCloskey It doesn't work because you use path: path.resolve(__dirname, build/${ASSET_PATH}), i.e. CleanWebpackPlugin and webpack's output.clean try to remove files inside path.resolve(__dirname, build/${ASSET_PATH}).
Based on your configuration it is expected, so you allow to download old version of your application, anyway if you want to make it work you need to specify filename: ${ASSET_PATH}/[name].[fullhash].js (same for chunkFilename/assetsFilename and other *filename options) and path: path.resolve(__dirname, "build"), so the root of your assets will be the build directory and everything inside will be cleaned, but your problem is not related to report
Fixed: when you have writeToDisk: true, still have some limitations:
- If you don't have
writeToDiskoption and still see thedistdirectory it's because we try to avoid extra removing due erf reasosns, because it is development enviroments - If you have
writeToDisk: (pathToFile) => /regexp/.test(pathToFile)still buggy
@alexander-akait
Bug still preset in [email protected] when it runs via webpack serve and when we have both output.clean: true and writeToDisk: true
@olosegres Please provide reproducible test repo, writeToDisk: true was fixed a long time ago