Production build hangs at 92%

Hello,

I think this is probably a bug with this plugin since the dev build works fine and when I run webpack --progress it gets stuck in:

92% chunk asset optimization UglifyJSPlugin

Below, the relevant parts of my webpack.config:

....

module.exports = {
    mode,
    node: { fs: 'empty' },
    entry: {
        ...entries
    },

    output: {
        filename: '[name].js',
        path: path.join(__dirname, '/public/assets/')
    },

    module: {
        rules: [
            {
                test: /\.js?$/,
                exclude: /(node_modules)/,
                use: 'babel-loader'
            },
            {
                test: /\.(scss|css)$/,
                use: [
                    MiniCssExtractPlugin.loader,

                    {
                        loader: 'css-loader'
                    },
                    {
                        loader: 'sass-loader',
                        options: {
                            sourceMap: true
                        }
                    }
                ]
            }
        ]
    },

    plugins: [
        new MiniCssExtractPlugin({
            filename: '[name].css'
        })
    ],

    resolve: {
        alias: {
            core: path.join(__dirname, 'js/core')
        }
    },

    optimization: {
        splitChunks: {
            minSize: 100000,
            chunks: 'initial',
            maxAsyncRequests: Infinity,
            maxInitialRequests: Infinity,
            name: true,
            cacheGroups: {
                styles: {
                    name: 'core',
                    test: /\.(scss|css)$/,
                    chunks: 'all',
                    enforce: true
                },
                vendor: {
                    name: 'vendor',
                    test: function (module) {
                        return /\/node_modules\//.test(module.context)
                    }
                },
                'core': {
                    name: 'core',
                    test: function (module) {
                        return /live-core\//.test(module.context)
                    }
                }
            }
        }
    }
}

Is this enough info? I tried to run with --debug --progress --display-error-details --verbose but nothing else came out

Well, I post the config in case there is an error on it - if you don't spot an error I can create a repo that reproduces the error,

Thanks in advance 😊

Instead of using the build-in module from webpack, when actually use the plugin on my webpack-config.js adding it to the plugins array and in dev mode, it works as expected, productionfails again.
Perhaps it's related to webpack.. 🤔

Still experimenting...

Using -p seems to be the reason that I get stuck. (maybe it's the only way to activate the plugin?)

Using https://github.com/pingyuanChen/webpack-uglify-js-plugin works on -p mode, it was the workaround to get going for now

@melloc01

@melloc01 can you create minimum reproducible test repo?

@melloc01

@melloc01 Friendly ping 👍

@evilebottnawi

Thanks @evilebottnawi
Did not forget - just overloaded with other upgrade issues. HMR now :|

Will save some time on the weekend to set up the repo

News: someone on Gitter is having the same issue

Same here, and I get out of memory error after a while:

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

This error happens to me every time I tried to use UglifyJSPlugin.

My dependencies:

{
    "autodll-webpack-plugin": ">=0.3.9",
    "autoprefixer": ">=8.2.0",
    "babel-loader": ">=8.0.0-beta.2",
    "babel-plugin-import": ">=1.7.0",
    "circular-dependency-plugin": ">=5.0.1",
    "compression-webpack-plugin": ">=1.1.11",
    "css-loader": ">=0.28.11",
    "file-loader": ">=1.1.11",
    "font-loader": ">=0.1.2",
    "happypack": ">=5.0.0-beta.3",
    "html-webpack-plugin": ">=3.2.0",
    "lodash": ">=4.17.5",
    "null-loader": ">=0.1.1",
    "postcss-loader": ">=2.1.3",
    "preload-image-loader": ">=1.0.0",
    "react-hot-loader": ">=4.0.1",
    "resolve-url-loader": ">=2.3.0",
    "sass-loader": ">=6.0.7",
    "stats-webpack-plugin": ">=0.6.2",
    "style-loader": ">=0.20.3",
    "uglifyjs-webpack-plugin": ">=1.2.4",
    "webpack": ">=4.5.0",
    "webpack-cli": ">=2.0.14"
  }

@zlk89

@zlk89 do you use latest version?

@zlk89

@zlk89 Also please create new issue, your problem is other

I just upgraded to webpack 4 (4.5.0) and I'm experiencing the same. It takes ages to finish the build process as it gets stuck on 92%.

@erickwilder

@erickwilder Can you crete minimum reproducible test repo?

My issue was apparently caused by the compress: true option of uglify - which is the default. Setting a custom uglify plugin instance overriding this configuration under the plugins list had no effect to change the compilation behavior.

I did solve it by moving uglify from the plugins to the optimization.minimizer list.

optimization.minimizer: [ new UglifyJsPlugin(...custom options) ]

Unfortunately this was the work of some digging through the code and other people's setup - I didn't find clear documentation about it.

@erickwilder

@erickwilder in webpack@4 you don't use plugins for minification, use minimizer property. If you use plugin field you have 2 instance of plugin. But will be great minimum reproducible test repo. In theory it is don't hangs.

@evilebottnawi

@evilebottnawi actually, if you specify the minimize property you just overwrite the default (built-in) UglifyJS as seen here:
https://survivejs.com/webpack/optimizing/minifying/

I actually set up a dummy repo that mimics the file structure (w/ dummy modules) of the original project but unfortunately it didn't hang, so it's not reproducible using dummy modules

I'm up for a call if you wanna dig into it @evilebottnawi, it's private so I can't just put on gh =\

We're seeing this issue too - we've narrowed it down to source maps being the issue in our case. We have a lot of code (if I run Webpack without minifcation it produces some 600MB of JS) however if we turn on sourceMaps for Uglify in this build it effectively hangs. We're already running with extra heap as well.

I've found a few things that could be potential areas for improvement:

source maps are kept in memory in the task object (the inputSourceMap property), serialised, and passed to workers. This is adding a significant amount of memory pressure in our case - if caching is enabled would it make sense to write the inputSourceMap to disk instead and just store a reference to the filename in the task? It would then be read from disk in the worker.
sourcemaps are produced serially - could this also be parallelised using the TaskRunner? I'm seeing long periods of "only" 100% CPU usage while sourcemaps are generated.

I am still experimenting with improvements locally, to see whether there is actually significant impact, but wondering what the appetite for these kinds of changes would be?

After investigating this more it's not as easy as it seems - within wepback-sources (where the code for sourceAndMap exists) the source map is also cached in memory. So removing it from memory in the uglify plugin won't make a difference to memory usage as it's still retained within the asset.

Unfortunately, I don't think there's much that can be done with the current architecture to alleviate the memory pressure - I believe there's more significant architectural changes planned for Webpack 5 that'll move more caching to disk.

In the meantime I've had a bit more success with using the cheap-module-source-map - it's still not as fast as Webpack 3 for our build, but at least it completes and doesn't OOM.

I didn't get around to trying parallelising source map generation.

Important to note that all these results are running a custom fork of uglifyjs-webpack-plugin that uses the new version of source-map - there is a serious performance issue in the version that ships with the plugin, essentially half the runtime is spent doing .split(/\\+/) - the new version replaces this with a non-regex method. It's a different issue (#248), I wonder if that perf fix could be backported to a version of source-map that's still Node 6 compatible.

@marcins

@marcins I followed your suggestion and opened an issue to backport the performance fix to 0.6 (mozilla/source-map#370)

I've noticed that this will manifest if there is a discrepancy between a slick table definition and the case class that represents the row. In my case it was a column defined as a Option[String] while the case class attribute was an Option[Long].
Instead of causing a compile error what actually happens is the compiler will hang one it starts to compile the slick based persistence and will run until it eventually hits its memory limit.
So if that happens to you it could be a code issue and not a Java / SBT / eclipse setting

I had the same problem.
I am solved by correcting a regex. I suppressed all "Named capturing group" regex feature.
And, it work again...

The problem is that Uglify does not say that it loops on a regex.

Does anyone know if this issue got fixed. We're still experiencing it.

@sumantka

@sumantka unfortunately we couldn't get this fixed on the main uglify branch, but the community has decided to fork uglify and make a new minifier called terser. It should be identical except terser is more optimized and effecient. If you look at webpack docs they even only recommend the terser plugin. There should be no work switching other then actually using a different loader and plugin because again this was a fork of uglify

@mlavina

Thanks @mlavina Unfortunately that doesn't seem to be the issue, or atleast that's what it looks like. It seems webpack by default adds some plugins in prod mode, terser is one. Now it seems to be failing at that. So not sure if it's inherently a problem of terser or some other plugin. Thanks for the context though

@sumantka

@sumantka after I switched to Terser I didn't experience the issue anymore, check if you're not forcing uglifyjs as a minifier on your config maybe? Otherwise I think you should open an issue on the Terser repo.

Temp solution, just to make it work (without minifying): Setting chunkFilter: () => false solved the problem for me:

const TerserPlugin = require('terser-webpack-plugin');

optimization: {
  minimizer: [
    new TerserPlugin({
      chunkFilter: () => false, // <-- set to false
    }),
  ],
},

@knapcio

Setting chunkFilter: () => false solved the problem for me

I'm pretty sure that turns off minifying altogether.

From the main readme of the repo:

chunkFilter

Type: Function<(chunk) -> boolean>
Default: () => true

Allowing to filter which chunks should be uglified (by default all chunks are uglified).
Return true to uglify the chunk, false otherwise.

I'm 99% sure that 'uglified' and 'uglify' in this context means 'apply the plugin to minify the code of the chunk'.

I doubt you want to turn off minifying completely, @knapcio?

Problem inside uglifyjs, they have problem(s) in code where you get infinity loop and webpack is freeze, no workaround for this plugin, please use terser-webpack-plugin

I came to this thread because I am experiencing the issue after having just migrated from Webpack v2 to v4, but not using Uglify at all. Just using the default minimizer. mode is production.

@papiro

@papiro do you use WSL?

Navigation Menu

Repository navigation

Production build hangs at 92% #272

75 remaining items

`chunkFilter`

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Production build hangs at 92% #272

Description

Activity

melloc01 commented on Apr 3, 2018

melloc01 commented on Apr 3, 2018

melloc01 commented on Apr 3, 2018

alexander-akait commented on Apr 4, 2018

alexander-akait commented on Apr 6, 2018

melloc01 commented on Apr 6, 2018

zlk89 commented on Apr 7, 2018

alexander-akait commented on Apr 7, 2018

alexander-akait commented on Apr 7, 2018

erickwilder commented on Apr 9, 2018

alexander-akait commented on Apr 9, 2018

erickwilder commented on Apr 10, 2018

alexander-akait commented on Apr 10, 2018

melloc01 commented on Apr 10, 2018

75 remaining items

marcins commented on Oct 3, 2018

marcins commented on Oct 5, 2018

benthemonkey commented on Nov 5, 2018

normana400 commented on Nov 19, 2018

Bonbons commented on Dec 3, 2018

Bonbons commented on Dec 3, 2018

sumantka commented on May 29, 2019

mlavina commented on May 29, 2019

sumantka commented on May 29, 2019

melloc01 commented on Jun 6, 2019

knapcio commented on Jun 26, 2019

ReinisV commented on Jun 26, 2019

chunkFilter

alexander-akait commented on Jun 26, 2019

papiro commented on Oct 1, 2019

alexander-akait commented on Oct 1, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`chunkFilter`