large webpack build almost hangs at 91%% on an “additional asset processing” step

Do you want to request a feature or report a bug?
possible bug

I have already asked on StackOverflow and it seems as if this behavior would be quite common but there have been no possible solutions.

What is the current behavior?
I have a large webpack build that almost hangs at 91%% on an “additional asset processing” step.
To complete processing take about 8 minutes but the step “additional asset processing” consumes at lwat half of the time.
Webpack does not give me a lot more information and I would like to better understand if this is “normal”, a bug or what can be done to eventually optimize my build?

56205ms building modules
31ms sealing
0ms optimizing
0ms basic module optimization
15ms module optimization
0ms advanced module optimization
0ms basic chunk optimization
0ms chunk optimization
16ms advanced chunk optimization
14487ms building modules
0ms module and chunk tree optimization
31ms module reviving
0ms module order optimization
16ms module id optimization
0ms chunk reviving
16ms chunk order optimization
31ms chunk id optimization
140ms hashing
0ms module assets processing
265ms chunk assets processing
0ms additional chunk assets processing
0ms recording
206740ms additional asset processing
79781ms chunk asset optimization
1ms asset optimization
906ms emitting

If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
faster or more information on what is currently being done

If this is a feature request, what is motivation or use case for changing the behavior?

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
node: 6.10.0
webpack: 2.3.1
OS: Windows 7 x64

Author: Fantashit

12 thoughts on “large webpack build almost hangs at 91%% on an “additional asset processing” step

  1. At the latest v2.3.3 update wrote that

    Fix performance issue with cheap-source-maps

    But I still have the same problem.

  2. I upgrade to latest webpack due to this issue, but still same it usually takes around 10 minutes for dist build and most of this time is haning on 91%% additional asset processing

  3. I found a solution. Simple add more memory for running with –max-old-space-size param
    node ... --max-old-space-size=8192

  4. Its probably UglifyJSPlugin or UglifyJsParallelPlugin. Try commenting that out and see if that makes things faster.

  5. My team’s project always hangs on 91%% and then sits for a bit on 92%%, but removing UglifyJSPlugin fixed the 91%% hang.

  6. I have this issue too. Finally found out that webpack 3.5.5 and Extract text plugin 3.0.0 combo will cause this problem. Each incremental dev build will take about 20 seconds which is unacceptable.
    Seems like webpack is busy processing and extracting css which is not modified at all.
    After I change webpack to 2.7.0 and Extract text plugin to 2.1.2, the incremental build took about 3 seconds. 😜

  7. Why was this closed? I’m still having this issue after trying several different workarounds posted. I’m still seeing a lot of people commenting on various threads that are experiencing the same thing. The only way I can resolve is setting the webpack devtool to ‘eval’, but that’s not supposed to be used for production.

  8. I’ve been debugging this issue and found out it is probably a bug in UglifyJS, see: mishoo/UglifyJS#2609

    I’m able to avoid the 91%% hang by passing { compress: false } to UglifyJSPlugin, eg:

    new UglifyJSPlugin({
          parallel: true,
          uglifyOptions: {
            ecma: 6,
            compress: false // hangs without this
          },
          cache: path.join(__dirname, 'webpack-cache/uglify-cache'),
        })
  9. @yantakus – not sure how you are chunking, but I’ve found it really easy to duplicate a ton of dependencies if you don’t start the plugin chain with a something like

    new webpack.optimize.CommonsChunkPlugin({
                children: true,
                async: true,
                minChunks: 3
            })
    

    Adding this reduced my chunked out size from 208Mb to 6.3Mb

  10. I seem to be having the same issue on Webpack 4 no matter which plugin I’m using, UglifyJS, babel-minify etc, they all hang at chunk assets processing and sit there until I run out of RAM

Comments are closed.