-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using webpack 4 on a large project (or, how to avoid "JavaScript heap out of memory" with production mode) #6389
Comments
@tschaub |
Thanks for the response @evilebottnawi. I'll try with |
@tschaub can you add after cache ("require('fs').writeFileSync( |
@tschaub also can you disable |
@evilebottnawi - I think disabling I can reenable the cache and dump the |
@evilebottnawi it looks like it successfully serializes cache keys for each of the 165 entry points. Here is the key for the final one: https://gist.github.com/tschaub/af36fa5ad8837fad0c5fced2a4345380 (most of the keys are around 1.5 MB). Is the cache used for incremental builds? I'm guessing the solution will be to disable it for many entry points. |
@evilebottnawi Wouldn't a lot of memory be saved if a hash of the cache identifier is used as the |
Yep, we should consider adding |
@tschaub thanks for helping |
@webpack-bot move to webpack-contrib/uglifyjs-webpack-plugin |
I've moved it to webpack-contrib/uglifyjs-webpack-plugin. |
Thanks for the help with this! |
I recently had a very similar issue occurring with the current latest stable release of In summary, I recommend moving to
So yeah, if you find yourself on this thread, I hope this helps you! |
@KarimNahas It looks like webpack 4 already uses |
An still the issue continues |
For those looking to increase the memory used by webpack, the solution is to not use the webpack batch file/shell script but call this instead:
That command gives 4GB of memory to webpack. |
I have allocated max old space to 8192 but still same error any idea or comments... |
@skirankumar7 - any time I've run into a case where 8gb wasn't enough (with any node script, not just webpack) it was due to a misconfiguration on my part. |
@slapbox Could you perhaps provide examples of such misconfiguration? I'm seeing this issue on a fairly empty nuxt.js + typescript project. |
Please try to update terser-webpack-plugin to the latest version |
Actually, I noticed something weird. My issue is with |
Update Node versión from v8.16.0 to v12.6.0 and that issue is gone! |
@NextTrick updating to latest LTS node resolved the issue for me as well, 10.x to 12.x |
12.x is not a guarantee: I’ve been using 12.x for months and frequently see OOM crashes. |
Please update terser-webpack-plugin to latest version |
On 12.x and still having OOM crashes. This seems like it could be a multitude of things. Possibly I have to change up my configuration but also possible that there are some issues internally as well. |
Reducing parallelism (default=100) worked for me. I was seeing an OOM during the build process. It would OOM somewhere above 30 active modules. (keep an eye on this line and the number active - This is specific to solving an OOM during the module build phase. This doesn't address OOMs during minification. |
@johnstew and @warmbowski Can you create reproducible test repo? |
I am also experiencing this issue with a reasonably small project. I have two configs exported in
I get OOM when using
I am using |
@boyanio hm, can you provide reproducible test repo I can look at the problem deeply? Maybe memory leak on |
@evilebottnawi Thanks for the quick response! I will try to create one, because the code I am working on is private. But so far I can confirm that removing the devtool from the TypeScript config produces a normal build. |
Some further findings: setting |
Can you clarify? |
@evilebottnawi I meant that without a devtool (which was set to |
@boyanio Maybe you can provide example? No need provide real code, maybe just multiple same examples, I think we can reduce memory usage |
@evilebottnawi I have created this repo https://github.com/boyanio/webpack4-memory-issue It is very close to what we have as configuration. The code is dummy there, but yet, our project is not that big: 438 .ts files and 285 .less files |
@boyanio Just note - I recommend to migrate on official CSS minimizer plugin https://github.com/webpack-contrib/css-minimizer-webpack-plugin, instead |
/cc @johnnyreilly |
Do you want to request a feature or report a bug?
Maybe this a feature request. I'm really looking for suggestions on using webpack (4) with many entry points (~165), a large set of dependencies, and a lot of shared code between entry points.
I guess it could also be considered a bug since
webpack --mode production
fails andwebpack --mode development --watch
succeeds.In this case, we are in the midst of migrating the OpenLayers project to ES modules, and would like to use webpack to build our examples (in development and for production).
What is the current behavior?
Given a webpack config that looks like this:
Running webpack in development mode works as expected:
(4.6 seconds is awesome for 165 entry points.)
However, when I try to run the same in production mode, I get out of memory errors.
If the current behavior is a bug, please provide the steps to reproduce.
Here is a tree with everything: https://github.com/openlayers/openlayers/tree/323a56b06c69af9ef56c2624e877b45ad2dd8fae
Here are the steps to get things set up:
Note that
npm run build -- --mode development
succeeds, but production mode fails.What is the expected behavior?
Since development mode works with many entry points, and production mode works with a few entry points, I was hoping that production mode would work with many entry points.
If this is a feature request, what is motivation or use case for changing the behavior?
Production builds fail on my machine and on Travis CI. I'm hoping that to get a production build to succeed, it doesn't require OS configuration changes for everyone involved.
Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
node@8.9.1
webpack@4.0.0-beta.0
macOS@10.13.2 (16 GB Memory, 3.5 GHz intel Core i7)
Thanks for the amazing work on webpack 4. Really looking forward to making use of it.
The text was updated successfully, but these errors were encountered: