Process out of memory – Webpack

16 thoughts on “Process out of memory – Webpack”

1. Don’t use hashes when watching. i. e. [chunkhash] causes all assets to be stored.

2. @sokra In the documentation for css-loader it says to use hash for easier debugging wrt css modules. Does that have the same problem?

   You can configure the generated ident with the localIdentName query parameter (default [hash:base64]). Example: css-loader?localIdentName=[path][name]---[local]---[hash:base64:5] for easier debugging.

   We’ve also started to see this problem in dev (out of memory), but our only hash in dev mode is the css one.

   EDIT: Of course it uses hash by default, so I’m guessing it’s not a problem.

3. jup.

   You can navigate to http://localhost:8080/webpack-dev-server to see a list of all files in memory.

4. We have the exact same memory leak problem after using webpack -w on MacOS X. Can you please suggest what is a the best way to fix / workaround this issue. The ngOfficeUIFabric seems to deal with a different problem.

   Thanks,
   Deepak

5. Having the same problem running webpack via webpack-stream in gulp. I use gulp.watch to rerun on code changes, which then just runs

       return gulp.src(tsStartFile)
                 .pipe(webpackStream(webPackConfig))
                 .on('error', logError) 
                 .pipe(gulp.dest(outputDir))
   

   I’d have thought this would run webpack from scratch each time, but after 5 or so builds I get the out of memory error and have to rerun my gulp file.

6. Did someone resolved this problem？

7. Another data point here; I have filename hashes disabled and my build isn’t terribly large (it uses Angular 2, but few other dependencies), but after about an hour of dev work the watch dies with Abort trap: 6.

   I’ve temporarily increased the memory limit, which gives me a lot more time, but I’d rather not be consuming gigabytes just to run a watch command.

   FYI if anyone is curious about upping the memory limit, I did it like so in my package.json (obviously the additional flags are dependent on your needs):

   {
     "scripts": {
       "start": "node --max_old_space_size=4096 node_modules/webpack-dev-server/bin/webpack-dev-server.js --inline --progress --port 3000 --open"
     }
   }

8. Having the same issue as @thunderkid here. Any update?

9. Same issue for a very small project

10. export NODE_OPTIONS=--max_old_space_size=4096

    Works for me.

11. Not sure if this is going to help anyone but we had a problem after updating to webpack 4 with the out of memory error. The build itself would often get stuck or become very slow. What very unexpectedly helped us was removing the BundleAnalyzerPlugin.

12. I got this in production mode, but not development 🤷‍♂️

13. I had this problem with the version 10.. of node but, when I upgraded to the v12.4.0 the error gone.

14. @buildbreakdo A better option is to do this:

    "scripts": {
        "build": "cross-env NODE_OPTIONS=--max_old_space_size=8192 webpack"
    }

    (It uses the cross-env package.)

    The nice thing about using NODE_OPTIONS is that it will affect everything, including any sub-processes that Webpack might spawn.

    (It’s useful for non-Webpack things as well: we’re using it for TypeDoc, which consumes a lot of RAM.)

    This solution did resolve the problem in my project.

15. remove max_old_space_size

    just add to ts-loader

               loader: 'ts-loader',
               options: {
                 transpileOnly: true // this works for me
               }
    

16. Memory leak found suguru03/neo-async#83

Comments are closed.