Delete unused webpack chunked files

Question

I\'m looking for information on how to delete old webpack chunked files. Here is my current webpack configuration:

var path = require(\'path\');
var webpack          


        

Answer 1

I have solved that problem by adding below in webpack.config.js

const { CleanWebpackPlugin } = require('clean-webpack-plugin');    
{
  ... your configs ...
  plugins: [new CleanWebpackPlugin()]
}

Answer 2

Here is the webpack-clean-obsolete-chunks plugin, which do what you want. It searches for all updated chunks and deletes obsolete files after each webpack compilation.

Answer 3

For Windows users

  "scripts": {
    "build": "npm run clean && webpack --mode production",
    "clean": "del /f /s /q dist 1>nul"
  }

Answer 4

The answer

I've decided to write an answer because others - although trying to answer the question directly - overlooked the most important part in my opinion.

And the most important part is: you shouldn't be doing it this way. Using [hash] placeholders in your development setup cause many headaches with other tooling (phpstorm's path autocomplete in symfony plugin for example). Also it's poor for webpack's incremental compilation performance and thus is not recommended by official webpack docs (reference).

So for future readers: just keep it simple for development config - define your filename as [name].js and move on.

Edit

There seems to be a confusion about what to do with the old chunk-files on the production server. Well, you don't do anything. Once a version is deployed it shouldn't be ever changed. You just keep creating new versions when deploying and keep previous as a backup. Why?

Because you want you're rollback to be reliable and for it to be possible your rollback needs to be extremely simple and atomic. If your rollback procedure is doing anything more than switching a symlink, rerouting to previous container (or similar simple operation) you're probably™ going to end up in trouble.

Rollback isn't a process of "re-deploying" the application again, but now to the previous version. It's a process of "un-doing" the deployment. So doing a git checkout to the previous version followed by a npm build --but-please-be-hurry --and-im-begging-you-dont-fail while your production app is hanging there, completely exploded doesn't cut here.

Rebuilding a previous version of the application - just like the deployment - may fail for many reasons. That's why a rollback should be switching/rerouting back to the exact same version-build that is proven to be working. Not ==-the-same, 100% ===-the-same. That's why you need to keep your previous version around, because that's the ===-same. A "regenerated" one is - in best case scenario - only ==-the-same, and so it is not proven to be working, only assumed.

And no, no amount of CI, staging environments or whatever will give you a guaranteed successful deployment. Part of doing it the right way is to be prepared for when things go wrong. And things will go wrong. Hopefully only from time to time, but still.

Of course once you have 3, 5 or <put-your-number-here> versions backed up you may start to remove the oldest ones as you probably won't ever need more than 3.

Answer 5

Take a look at this pull request: https://github.com/johnagan/clean-webpack-plugin/pull/32/files

Open raw file view and copy it to index.js of clean webpack plugin. Remember about config flag -> watch: true

Answer 6

There is a clean-webpack-plugin for those purposes, or you can write a simple bash script for npm:

 "scripts": {
    "build": "rm -r dist/* && webpack -p",
    "clean": "rm -r dist/*"
  }