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

[doberkofler]

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

[sokra]

duplicate of #4550

[doberkofler]

@sokra It looks very similar but in my case, the upgrade to 2.3.1 actually improved the performance by about 10%. The performance actually started to slow down when migrating from webpack1 to 2. Is there anything I can do to track down where the time is lost to eventually help?

[igor-lemon]

At the latest v2.3.3 update wrote that

Fix performance issue with cheap-source-maps

But I still have the same problem.

[obykoo]

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

[hsingh23]

I also have this problem for production builds
I use devtool: 'source-map',

[leyyinad]

Happens for me only when using babili-webpack-plugin

[j-nord]

It hangs on each large file at 91%. It takes a lot of time and finally provides the error message: Not enough memory.

Hardly to use.

[igor-lemon]

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

[j-nord]

Thanks for the answer!

But that does not solve the problem that you have to wait on a fast computer over 10 minutes with 25% CPU usage and over 1 GB of memory each time to the completion.

That is to long!

[dhatawesomedude]

@leyyinad I have the same issue. Mine takes about 4minutes at 91% with babili-webpack-plugin enabled.

[leyyinad]

See here: babel/minify#332

[dhatawesomedude]

I already tried that. It fixes the initial issue of the build failing to complete, but the issue with being stuck at 91% processing still remains.

[mrampson]

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

[EthanStandel]

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

[matt-lough]

@EthanStandel I can also confirm that I just removed the UglifyJSPlugin and it fixed the 91% hang in my project

[doberkofler]

I originally opened this SR and can also confirm, that there have been a few minor (~10%) performance improvements in webpack but most of the time is still consumed in the UglifyJSPlugin. In my current environment webpack does not actually hang but the additional asset processing step can take up to 10 minutes.

[rjarmstrong]

Don't rely on Webpack plugins for everything e.g. we are using this in Go and its WAAAY faster: https://github.com/tdewolff/minify with maybe slightly less optimisations.

[crazyxhz]

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. 😜

[disco-dev]

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.

[andreialecu]

I hate to +1 this, but I have been working around this problem for a long time, and I can probably provide more info:

The only way acceptable way I can get my builds to succeed is to use https://github.com/gdborton/webpack-parallel-uglify-plugin and ensure it uses UglifyJS instead of UglifyES. If I set that plugin into UglifyES mode it will hang at 91% just as the main webpack uglify plugin.

Builds also succeed if devtool is set to eval using either of the two plugins in uglify-esmode. Any other devtool doesn't work, including the null/undefined option, which I'm using anyway. devtool: "eval" builds however are huge.

I've tracked this down to @angular/core. If I remove the require to it in the code, builds minify properly regardless of the devtool setting, and with either plugin.

Now the question is why does devtool: "eval" make this work, but devtool: null doesn't?

Could this be reopened?

I've been using webpack 2 while struggling with this, have just now upgraded my entire setup to webpack 3.10.0 and everything I said above is still valid.

[andreialecu]

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'),
    })

[aapoalas]

Having this same problem. Our devtool option is set to inline-cheap-module-source-map.

Disabling UglifyJsPlugin does the trick, build passes. Funnily enough, so does setting devtool to eval.

Even funnier, unsetting devtool does not fix the problem. What?!

EDIT: Using version 1.1.5 of uglifyjs-webpack-plugin

EDIT2: Updating uglify-webpack-plugin to latest (1.2.2), adding uglifyOptions for process.env.NODE_ENV = "production" fixed this problem. Builds still take 4+ minutes.

[tim-soft]

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

[Dreamwalker420]

I experienced the same error on ng serve. I removed the following from the .angular-cli.json file.

            "styles": [
                "assets/css/styles.css"

            ],
            "scripts": [
                "assets/js/project.js"      

            ],

[MengChen2015]

my webpack version:@2.7.0 .
I also confirm that commenting out UglifyJsPlugin(or removing) solved my problem.Before it takes out 25 seconds on " hangs at 91% on an "additional asset processing" step,now it takes out 1-3 seconds.
/* new UglifyJsPlugin({
uglifyOptions: {
compress: true
},
sourceMap: true,
}),*/

[vputnin]

Hi! I am just set regExp for files extension, that I want to uglify

new UglifyJsPlugin({
        test: /\.js$/i,
        exclude: /node_modules/,
        uglifyOptions: {
          output: {
            comments: false
          }
        }
      })

This works for me. And what I found that, every next webpack build will be built much faster than previous. First my try was about 12 minutes, 6th try was about 2 minutes with the same configuration.
Webpack: v3.12.0
Node: v8.11.3

[chandansingh123]

91% additional asset processing scripts-webpack-plugin× ｢wdm｣: Error: ENOENT: no such file or directory, open 'C:\Users\chand\node_modules\jquery\dist\jquery.min.js'

[graveend]

Same issue:
91% additional asset processing scripts-webpack-pluginENOENT: no such file or directory, open 'C:\Users\graveendran\eclipse-workspace\node_modules\jquery\dist\jquery.min.js'

[FaizalMalik]

I have fixed this issue by removing the 'new webpack.optimize.UglifyJsPlugin({sourceMap: true}),'
from webpack config file - happy coding 👍

[doberkofler]

I originally opened this SR and for me the solution was to always use the latest webpack version and invoke node with the --max_old_space_size=4096 option. This permanently solved the problem for me!

[brienRosenquist]

The latest version of the angular devkit package (0.13.6) with the latest version of the webpack-env package (1.13.9) seems to have solved this problem.

[toanbku]

Same problem when I deploy on server. In my case, I just fix it by increasing the swap ram area.

sudo fallocate -l 4G /swapfile && \
sudo chmod 600 /swapfile && \
sudo mkswap /swapfile && \
sudo swapon /swapfile && \
sudo swapon -s && \
sudo cp /etc/fstab /etc/fstab.bak && \
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

[ramsunvtech]

Below settings helped me to reduce the heap memory since it will not include the sourceMap file.

devtool: false, // Webpack.

new webpack.optimize.UglifyJsPlugin({
   sourceMap: shouldUseSourceMap
}),

or below code will help for latest webpack uglify plugin.

> npm install uglifyjs-webpack-plugin --save-dev

// conf.js
const UglifyJsPlugin = require('uglifyjs-webpack-plugin');
module.exports = {
  optimization: {
    minimizer: [
      new UglifyJsPlugin({
        sourceMap: true,
      }),
    ],
  },
};

If this still not help to fix the problem. below command helps to increase heap memory and answer link to know more about heap memory is below as well.

node --max-old-space-size=16000 scripts/build.js

https://stackoverflow.com/a/57480923/1533666

[Nghiemducnam]

I met the same case, you can try this statement in terminal: npm i