webpack hangs in middle when '--p' is used always on 68%

[S1E-]

I am using vuejs Loader. When I run the command "production" === "webpack --p --progress". It always get struck at 68% and keeping stucking there forever. Can anyone suggest why is this happening and how can I resolve this.

this is my web.config.js

var webpack = require('webpack');
var StatsWriterPlugin = require("webpack-stats-plugin").StatsWriterPlugin;
var OfflinePlugin = require('offline-plugin');


module.exports = {
  entry: {
    build: './src/index.js',
    restJS: './src/restJS.js'
  },
  output: {
    path: './dist',
    publicPath: 'dist/',
    filename: '[name].js'
  },
  module: {
    loaders: [{
      test: /\.vue$/,
      loader: 'vue'
    }, {
      test: /\.js$/,
      loader: 'babel',
      exclude: /node_modules/,
      query: {
        presets: ['es2015'],
        plugins: ['transform-runtime']
      }
    }, {
      // edit this for additional asset file types
      test: /\.jpe?g$|\.gif$|\.png$|\.svg$|\.woff(\d*)\??(\d*)$|\.ttf\??(\d*)$|\.wav$|\.mp3$|\.eot\??(\d*)$|\.svg\??(\d*)$|\.html$/,
      loader: "file-loader"
    }, {
      test: /\.scss$/,
      loader: "style!css!sass"
    }, {
      test: /\.css$/,
      loaders: ["style", "css"]
    }]
  }

};

this is my package.json

{
  "name": "",
  "version": "",
  "description": "",
  "author": "",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "webpack --progress --colors --watch",
    "watch" : "webpack --progress --colors",
    "dev": "webpack-dev-server --watch --inline --hot",
    "build": "webpack --progress --colors --watch --optimize-dedupe --optimize-max-chunks 15 --optimize-min-chunk-size 10000",
    "analysis":"webpack  --json | analyze-bundle-size",
    "production": "webpack --p --progress"
  },
  "dependencies": {
    "babel-plugin-transform-runtime": "^6.1.18",
    "css-loader": "^0.23.0",
    "file-loader": "^0.8.5",
    "google-maps": "^3.1.0",
    "hammerjs": "^2.0.4",
    "install": "^0.3.0",
    "jade": "^1.11.0",
    "jquery": "^2.1.4",
    "materialize-css": "^0.97.3",
    "node-sass": "^3.4.2",
    "npm": "^3.5.0",
    "opentok": "^2.3.0",
    "sass-loader": "^3.1.2",
    "style-loader": "^0.13.0",
    "template-html-loader": "0.0.3",
    "testimonial": "^2.0.1",
    "url-loader": "^0.5.7",
    "vide": "^0.4.1",
    "vue": "^1.0.10",
    "vue-async-data": "^1.0.2",
    "vue-hot-reload-api": "^1.2.1",
    "vue-html-loader": "^1.0.0",
    "vue-loader": "^7.1.4",
    "vue-resource": "^0.1.17",
    "vue-router": "^0.7.7",
    "vue-validator": "^1.4.4",
    "webfont-medical-icons": "^0.9.3",
    "webpack": "^1.12.9",
    "webpack-dev-server": "^1.14.0"
  },
  "devDependencies": {
    "babel-core": "^6.2.1",
    "babel-loader": "^6.2.0",
    "babel-preset-es2015": "^6.1.18",
    "babel-runtime": "^6.2.0"
  }
}

[bebraw]

Maybe as a workaround you could get a non-minified output from Webpack and then pass it through Uglify separately. I know that's not neat but at least it would allow you to get ahead.

Possibly related issue: #537.

[S1E-]

I am getting an non-minified file and then minifying with php but after this also its size is still 1MB

[bebraw]

Check out the bundle carefully. It's probably bringing things there you might want to include.

Based on your setup it will inline CSS within the bundle. Consider setting up ExtractTextPlugin to get a separate bundle for CSS.

[S1E-]

@bebraw after extracting css, build.js is reduce by 18kb so practically its still of 1MB.

[bebraw]

@S1E- Yeah. There is something else going on. Perhaps some of your vendor dependencies are heavy or it includes code you don't want it to. There are tools like Webpack Chart that can give you a better idea.

[S1E-]

Size analysis of my build.js is

[S1E-]

webpack chart map of build.js

[bebraw]

Particularly materialize-css and crypto-js seem really big. You could try to analyze how you are using those. Maybe you just need a smaller subset of each.

You can load a dependency like jquery as an external. There are also code splitting techniques you can leverage.

To get back to the original issue, it would help a lot if you could set up a simplified test case that demonstrates the hang. Strip as much code as you can. This will make it easier to debug.

[S1E-]

Can you please suggest me to some resource? Where I can see that how I can I write a test to debug this issue.

[bebraw]

Essentially it would be about dropping as much material from your project while retaining the hang. At some point it will stop failing so you may need to step back.

You can try eliminating entire pieces of the project like styling for instance. There isn't any specific resource as it's just generic debugging to pinpoint the cause. 👍

Hopefully this process helps you to understand what triggers the issue.

[S1E-]

I have already tried that, all the files included in the bundled are used somewhere so when I remove any one of them then webpack throws error 'required file not found'

[bebraw]

Yeah, you would have to perform the changes on code level on a separate branch. No other way.

[S1E-]

OK and thanks

[sokra]

You could try the 2.0.7-beta version, which displays the module name in the progress thing. Maybe this helps to identify the point where it hangs..

[buremba]

I tried 2.0.7-beta but the message is similar, no mention of the module name. It was "additional asset processing"

[jkyoutsey]

I'm seeing the same issue and not uglifying. Today I did an npm install, first time in about a week. So I think something changed recently to cause this.

I consistently see this:
10% 0/2 build modulests-loader: Using typescript@1.7.5 and /Users/JARVIS/src/project7/tsconfig.json 68% 120/123 build modules

68% or 69% is the consistent mark with 119-121/123 built.
Isn't there any way to get more info on what's going on under the covers?

[Restuta]

Facing same issue, but I noticed one thing that it's not happening for
devtool: 'eval', but is happening for both:
devtool: 'source-map'
and
devtool: 'cheap-module-source-map'

Webpack 1.12.14

[bebraw]

Can you try against the current beta version of webpack 2?

[clemgrim]

Hello, I have the same issue with webpack 2.2.0-rc.3 and webpack.2.1.0-beta.28
It's blocking at 91%. No minification, no sourcemaps.
I'm using extract plugin (2.0) and awesome typescript loader.

[bebraw]

@clemgrim Could you set up a project so it's easier to debug what's going on?

[clemgrim]

Here is my config:

// load required modules
var path = require('path');
var webpack = require('webpack');
var autoprefixer = require('autoprefixer');

// load plugins
var CopyWebpackPlugin = require('copy-webpack-plugin');
var AssetsPlugin = require('assets-webpack-plugin');
var ExtractTextPlugin = require('extract-text-webpack-plugin');
var NgAnnotatePlugin = require('ng-annotate-webpack-plugin');

module.exports = function(options) {
   return {
        entry: {
            home: '/some/path/home.ts', // there're more entries
            vendor: '/some/path/vendor.ts')
        },
        output: {
            path: '/some/path/dist',
            filename: '[name].js',
            chunkFilename: '[id].chunk.js',
            publicPath: '/dist/',
            jsonpFunction: 'jsp'
        },
        resolve: {
            extensions: ['.ts', '.js'],
            modules: ['/some/path', 'node_modules'],
            unsafeCache: true
        },
        resolveLoader: {
            moduleExtensions: ['-loader']
        },
        module: {
            loaders: [
                {
                    test: /\.ts$/,
                    loader: 'awesome-typescript',
                    exclude: [/node_modules/]
                },
                {
                    test: /\.html/,
                    loader: 'html',
                    exclude: [/node_modules/]
                },
                {
                    test: /\.css$/,
                    loader: ExtractTextPlugin.extract({fallbackLoader: 'style', loader: options.prod ? 'css!postcss' : 'css'})
                },
                {
                    test: /\.scss/,
                    loader: ExtractTextPlugin.extract({fallbackLoader: 'style', loader: options.prod ? 'css!postcss!sass' : 'css!sass'})
                }
            ],
            noParse: [
                /angular.*\.js$/,
                /moment.*\.js$/,
                /ui-select.*\.js$/,
                /pdfjs-dist.*\.js$/,
                /ngmap.*\.js$/,
                /ng-file-upload.*\.js$/
            ]
        },
        plugins: [
            new webpack.optimize.CommonsChunkPlugin({names: ['vendor']}),
            new ExtractTextPlugin(options.prod ? '[name]-[chunkhash].css' : '[name].css'),
            new webpack.DefinePlugin({PRODUCTION: !!options.prod}),
            new AssetsPlugin({filename: 'manifest.json', path: absPath('data/webpack')}),
            new webpack.LoaderOptionsPlugin({
               minimize: options.prod,
               debug: false,
               options: {
                  htmlLoader: {
                     ignoreCustomFragments: [/\{\{.*?}}/],
                     attrs: false
                  },
                  postcss: function () {
                     return options.prod ? [autoprefixer] : [];
                 }
              }
            }),
            new NgAnnotatePlugin({add: true})
        ],
        node: {
            global: false,
            crypto: false,
            module: false,
            clearImmediate: false,
            setImmediate: false
        },
        devtool: false,
        profile: true,
        performance: {
            hints: false
        },
        stats: 'verbose',
        watchOptions: {
            ignored: [
                './node_modules/**/*',
                './module/**/*',
                './public/**/*',
                './vendor/**/*'
            ]
        }
    };
};

It takes ~25s (I optimized from 35 to 25s with noParse option)
But the 91% additional asset processing is taking a very long time, and I can't figure what is done in this step. there's no uglify plugin or whatever.
Note that I'm building 600+ modules

[dziamid]

Same problem here, hangs on 91% additional asset processing

[vperron]

Same here for us.

[mikeengland]

Same for me, but on 66%.

[mstralka]

The weird thing for me is that, with the exact same versions of node, npm, yarn, and all of the packages, I can run this on my Macbook Pro (macOS 10.12.3 with 16 GB RAM and SSD) and it will finish in about 50 seconds. On my Ubuntu 16.04 servers (8GB RAM AWS with SSD), it takes 15 minutes (hanging at 68% for a long time but it does eventually finish). So I have to perform the build step on my mac and then rsync the files to the servers.

Has anyone else experienced this where it will work on a Mac in a reasonable amount of time but it's dog slow on a Linux server with the same build tools?

[jeremyk]

I am having the same issue. With the -p option, the build takes about 10 minutes, handing around 30% but never in the same spot. Using any of the "eval" source map options fixes it but then the resulting file is much larger.

[sijakret]

same issue here with node 8.4.0

[urbanhusky]

Our production build is also failing after 91% additional asset processing with FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory.

We cannot skip minification or tree-shaking, as this would yield an unwieldy large application that is quite slow to load.

[urbanhusky]

I found a workaround for us

We replaced all webpack calls from our build scripts with node --max-old-space-size=6144 node_modules/webpack/bin/webpack.js.
In this case, we increased the node memory limit to 6GB (default seemed to be 1.5GB). Our build was hitting ~3GB, I went with 6GB as a limit to leave some headroom.

Comparison of old vs "fixed" solution

• from build script (in this case: patched into dotnet publish with an <Exec Command="…"> - because we build an asp.net core application)
• from package.json

new "fixed" workaround

# build script
node --max-old-space-size=6144 node_modules/webpack/bin/webpack.js --config config/webpack.config.vendor.js --env.prod -p

# package.json scripts:
"build-webpack-prod-vendor": "node --max-old-space-size=6144 node_modules/webpack/bin/webpack.js --config ./config/webpack.config.vendor.js --env.prod -p",

previous implementation

# build script
node_modules/webpack/bin/webpack.js --config config/webpack.config.vendor.js --env.prod -p

# package.json scripts:
"build-webpack-prod-vendor": "npm-run webpack --config ./config/webpack.config.vendor.js --env.prod -p",

Summary

Replaced npm-run webpack … with node --max-old-space-size=6144 node_modules/webpack/bin/webpack.js …
Replaced node_modules/webpack/bin/webpack.js … with node --max-old-space-size=6144 node_modules/webpack/bin/webpack.js …

Adjust --max-old-space-size=<maximum memory in MB> accordingly.

[scipper]

@urbanhusky icreasing the max memory does indeed fixed the hangs on 68-69%. thanks for that!

[andreialecu]

For everyone experiencing the 91% hang, let's get #4558 reopened. node --max-old-space-size=6144 does not help with that problem.

There has been some discussion there, but the issue has been closed prematurely.

[mnpenner]

I'm getting stuck at 70% with webpack 4.0.1:

❯ webpack --progress
 70% building modules 1682/1682 modules 0 active  

[alexander-akait]

@mnpenner can you create minimum reproducible test repo?

[montogeek]

@mnpenner Have you tried increasing your NodeJS memory limit? How big is your project?

[mnpenner]

@evilebottnawi Uhh... we'll see. I'm going to fight with it a bit more first. My config is rather complex.

@montogeek No, I haven't tried that. I should do something like this?

❯ node  --max-old-space-size=8192 "node_modules/.bin/webpack" --progress --color --sort-assets-by name --bail

Same result. It's not crashing though, so it doesn't seem like it's running out of memory.

My project has 514 "assets" -- I think all or most of those are processed by webpack.

The part I find weird though is that it says "1691/1691 modules 0 active" -- as though it's done. It seems like its getting confused.

I guess I'll wait for the v3 to v4 migration guide. Probably missed something. webpack-dev-server still runs, its just my production build that's hanging.

[alexander-akait]

@mnpenner try to enable/disable plugins and loaders

[jtomaszewski]

@mnpenner I had the same problem and for me the cause was extract-text-webpack-plugin. Switching to mini-css-extract-plugin solved it.

[mnpenner]

Thanks Jack. That worked for me too (switching to mini css) On Mar 27, 2018 12:53 AM, "Jack Tomaszewski" <notifications@github.com> wrote: @mnpenner <https://github.com/mnpenner> I had the same problem and for me the cause was extract-text-webpack-plugin. Switching to mini-css-extract-plugin solved it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2012 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD7phI-EC4S-5jFvxm_G67PP8BUrK0Yks5tie_9gaJpZM4HU1aB> .

[alexander-akait]

FYI webpack@2 is deprecated. Please upgrade you configuration to latest version and feel free to recreate issue if problem still exists. A lot of difference issues here and difficult support people. Thanks!

[Alabit]

I had a similar issue, google pointed me here. Leaving my findings for the future.
For me, it was related to sass/node-sass#857
For me, it only existed on webpack-dev-server with node-sass on Windows.

I resolved it by adding
UV_THREADPOOL_SIZE=1024 to my package.json build scripts

    "run-dev": "cross-env DEV='true' NODE_ENV=development BABEL_ENV=development NODE_OPTIONS=--max_old_space_size=8192 webpack-dev-server --config webpack.dev.js --progress --color",
    "run-dev-windows": "cross-env DEV='true' NODE_ENV=development BABEL_ENV=development NODE_OPTIONS=--max_old_space_size=8192 UV_THREADPOOL_SIZE=1024 webpack-dev-server --config webpack.dev.js --progress --color",

It slowed down my linux builds, so I split it into two scripts. But it turned my windows builds from never-finishing always-hanging to actually-completes (in about 3.5 minutes)

[denishowew]

For me, it was related to sass/node-sass#857

Thank you very much for this hint. webpack was hanging at the end of a run unless I set stats: 'none' or didn't apply sass-loader (redundantly) for CSS files.