Delete unused webpack chunked files

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 = require('webpack');

module.exports = {
  debug: false,
  outputPathinfo: true,
  displayErrorDetails: true,
  context: __dirname,
  entry: {
    common: ['./src/common.coffee'],
    a: './src/a.cjsx',
    b: './src/b.cjsx'
  },
  output: {
    filename: '[name]-[chunkhash].js',
    chunkFileName: '[name].[chunkhash].js',
    path: path.join(__dirname, 'js')
  },
  plugins: [
    new webpack.optimize.CommonsChunkPlugin('common', 'common-[chunkhash].js'),
    new webpack.optimize.UglifyJsPlugin({
      compress: { warnings: false }
    })
  ],
  module: {
    preLoaders: [
      {
        test: /\.coffee$/,
        exclude: /node_modules/,
        loader: 'coffeelint-loader'
      }
    ],
    loaders: [
      { test: /\.coffee/, loader: 'coffee' },
      { test: /\.cjsx$/, loaders: ['coffee', 'cjsx'] },
      { test: /\.js$/, loader: 'jsx-loader?harmony' }
    ]
  }
}

If I am running $(npm bin)/webpack --config webpack.js --watch and make changes to a.cjsx, it compiles a newer version of that file with a new chunkedhash. However, the old one remains and I'd like it to be deleted right away.

  1. How can I delete the old version of the chunked file?
  2. Is there a way for me to hook into an after callback once watch finishes compiling?

Answers:

Answer

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/*"
  }
Answer

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

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

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

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

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

You can solve the problem ? 1 by using remove-files-webpack-plugin.

Use this plugin like this:

plugins: [
  new RemovePlugin({
    watch: {
      test: [
        {
          folder: './js',
          method: (absPath) => new RegExp(/(.*)-([^-\\\/]+)\.js/).test(absPath)
        }
      ]
    }
  })
]

In "watch" mode (not normal compilation!) it grabs all files from ./js folder and tests them with this regular expression /(.*)-([^-\\\/]+)\.js/. Analyze this regular expression on regex101 (unit tests are included) if you have problems with understanding.

Note: i'm the creator of this plugin.

Tags

Recent Questions

Top Questions

Home Tags Terms of Service Privacy Policy DMCA Contact Us

©2020 All rights reserved.