92% chunk asset optimization - webpack

33,533

Solution 1

I too faced similar issue while running build remotely, So, in jenkin after adding following command, problem got resolved for me.

export "NODE_OPTIONS=--max_old_space_size=2000"

Solution 2

Run ng serve --sourceMap=false

Solution 3

I do a yarn cache cleaning and it fixed my issue "92% chunk asset optimization TerserPlugin" on my Ubuntu 16.04 host on google cloud.

Not sure if it works on your machine

yarn cache clean

I have this issue on 2nd machine, and this machine requires a reboot.

sudo reboot

Solution 4

I've had great success using a combination of the following:

https://github.com/mzgoddard/hard-source-webpack-plugin

and

https://github.com/amireh/happypack

HardSourceWebpackPlugin is a plugin for webpack to provide an intermediate caching step for modules. In order to see results, you'll need to run webpack twice with this plugin: the first build will take the normal amount of time. The second build will be signficantly faster.

HappyPack makes initial webpack builds faster by transforming files in parallel.

Report back and let me know how it goes.

Share:
33,533
Wonka
Author by

Wonka

Updated on August 30, 2021

Comments

  • Wonka
    Wonka over 2 years

    It seems that webpack gets stuck on 92% chunk asset optimization for about 30+ seconds to show a simple js/css change. This is too long for anyone sane to sit and wait that much of their life to see something that should be rendered near instantly.

    We're in development mode (so we need source maps, which add to the latency) but it should still NOT be 30+ seconds. Also, we're not using uglify (which I've seen mentioned on GitHub as taking up a good amount of time).

    How can we get the build time to be near instant, or much much faster than right now?

    UPDATE

    Here is the laravel-mix file:

    let mix = require('laravel-mix');
    
    mix.react('resources/assets/js/app.js', 'public/js')
       .sass('resources/assets/sass/app.scss', 'public/css')
       .options({
         processCssUrls: false
       });
    
    mix.webpackConfig({
        // Note: First build will always be slower regardless
        // Here we're talking about rebuild time
    
        // If commented out, rebuild is ~6 secs
        // devtool: "inline-source-map",
    
        // If not commented out, rebuild is 30+ secs
        devtool: "inline-source-map",
    });
    

    I found inline-source-map to be the best for quickest debugging, as it provides the most detail on which line of error to fix in source, very very straight forward on what to fix where. I find other types are more cryptic in comparison and there is no indication of which line number to fix in source, so it takes much longer to debug.

    How do you guys do it? Is there a way to rebuild really fast while still being able to debug with the error line number in source to fix it (shown in chrome devtools console)?