删除未使用的webpack chunked文件

Jey*_*ran 24 javascript webpack

我正在寻找有关如何删除旧webpack chunked文件的信息.这是我目前的webpack配置:

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' }
    ]
  }
}
Run Code Online (Sandbox Code Playgroud)

如果我正在运行$(npm bin)/webpack --config webpack.js --watch并进行更改a.cjsx,它会使用新的chunkedhash编译该文件的较新版本.然而,旧的仍然存在,我希望它立即被删除.

  1. 如何删除旧版本的chunked文件?
  2. 一旦手表完成编译,我有办法挂钩回调吗?

art*_*kin 17

有一个clean-webpack-plugin用于这些目的,或者你可以编写一个简单的bash脚本npm:

 "scripts": {
    "build": "rm -r dist/* && webpack -p",
    "clean": "rm -r dist/*"
  }
Run Code Online (Sandbox Code Playgroud)

  • 作者的意思是如何使用`--watch` cli选项删除带有`hash`的旧`chunk`. (14认同)

GPr*_*ost 11

这是webpack-clean-obsolete-chunks插件,它可以做你想要的.它会搜索所有更新的块,并在每次webpack编译后删除过时的文件.

  • 由于某些原因它什么都不做 (2认同)

GPr*_*ost 9

从 Webpack 5.20.0 开始,您可以使用output.clean选项


plu*_*iam 7

答案

我决定写一个答案,因为其他人 - 尽管试图直接回答这个问题 - 忽略了我认为最重要的部分。

最重要的部分是:你不应该这样做。[hash]在你的开发设置中使用占位符会给其他工具带来很多麻烦(例如 symfony 插件中的 phpstorm 路径自动完成)。此外,它对于 webpack 的增量编译性能也很差,因此官方 webpack 文档(参考)不推荐。

所以对于未来的读者:只需保持简单的开发配置 - 定义你的filenameas[name].js并继续。

编辑

关于如何处理生产服务器上的旧块文件似乎存在混淆。好吧,你什么都不做。一旦部署了版本,就不应再更改它。您只需在部署时不断创建新版本并保留以前的版本作为备份。为什么?

因为您希望回滚可靠,并且要使其成为可能,您的回滚需要非常简单和原子化。如果您的回滚过程所做的不仅仅是切换符号链接、重新路由到以前的容器(或类似的简单操作),您可能会™ 最终遇到麻烦。

回滚不是再次“重新部署”应用程序的过程,而是现在到以前的版本。这是一个“取消”部署的过程。所以git checkout对以前的版本做一个,然后npm build --but-please-be-hurry --and-im-begging-you-dont-fail你的生产应用程序挂在那里,完全爆炸不会在这里削减。

重建应用程序的先前版本 - 就像部署一样 - 可能由于多种原因而失败。这就是为什么回滚应该切换/重新路由回被证明有效的完全相同的版本构建。不==一样,100%===一样。这就是为什么您需要保留以前的版本,因为这是===相同的。一个“再生”的 - 在最好的情况下 - 只有==- 相同,所以它没有被证明是有效的,只是假设。

不,再多的 CI、暂存环境或其他任何东西都不能保证成功部署。以正确的方式做这件事的一部分是为出现问题做好准备。事情出错。希望只是不时,但仍然。

当然,一旦您<put-your-number-here>备份了3 个、5 个或多个版本,您就可以开始删除最旧的版本,因为您可能永远不需要超过 3 个。