webpack ng serve runs out of memory

[slubowsky]

Please provide us with the following information:

1. OS? Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?) Windows 10
2. Versions. Please run ng --version. If there's nothing outputted, please run in a Terminal: node --version and paste the result here: angular-cli: 1.0.0-beta.11-webpack.2 node: 6.3.1 os: win32 x64
3. Repro steps. Was this an app that wasn't created using the CLI? What change did you do on your code? etc. Keep ng serve running and serving a cli built app while coding for some time (a few hours?)
4. The log given by the failure. Normally this include a stack trace and some more information.

...
 94% asset optimization
<--- Last few GCs --->

12936118 ms: Mark-sweep 1360.3 (1435.0) -> 1356.1 (1435.0) MB, 959.3 / 0 ms [all
ocation failure] [GC in old space requested].
12936973 ms: Mark-sweep 1356.1 (1435.0) -> 1356.0 (1435.0) MB, 854.9 / 0 ms [all
ocation failure] [GC in old space requested].
12938085 ms: Mark-sweep 1356.0 (1435.0) -> 1356.0 (1435.0) MB, 1112.2 / 0 ms [la
st resort gc].
12939012 ms: Mark-sweep 1356.0 (1435.0) -> 1355.8 (1435.0) MB, 926.7 / 0 ms [las
t resort gc].

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 000001F1975C9E51 <JS Object>
    1: replace [native string.js:~129] [pc=0000018EE86B74E5] (this=000000EF14282
331 <String[61]: D:/it/node_modules/@angular/common/src/pipes/common_pipes.js>,
N=000000EF140824C9 <JS RegExp>,O=00000135F03D7F21 <String[10]: !(webpack)>)
    2: shorten [D:\it\node_modules\webpack\lib\RequestShortener.js:~41] [pc=000
0018EE4290DA2] (this=0000020E88D58019 <a RequestShortener with map 00000313C3C4.
..

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memo
ry

1. Mention any other details that might be useful.

Only happened once so far but thought it worth mentioning

---

Thanks! We'll be in touch soon.

[kylecordes]

I am thinking about a good way to test this. I already have a little stress test program that generates a working program with a given number of components. But unfortunately it also generates the exact same program each time. So I'm thinking about making it slightly randomize the contents of the programs it generates so that it generates changed files each time. Then run it in a loop and see how much RAM leaks.

[kylecordes]

OK, I made a way to test this. I enhanced the "angular 2 stress test" tool:

https://www.npmjs.com/package/angular2-stress-test

To stress test "ng serve":

• install angular2-stress-test
• ng new test-project
• cd test-project
• ng serve
• leave "serve" running, and make a second command window to work in
• cd src/app
• for i inseq 1 1000; do angular2-stress-test 500 -r ; sleep 5 ; done
• While that runs, keep an eye on RAM and CPU use the ng serve Node process

In my testing as above:

• Starting up the first time, ng serve uses 463MB of RAM
• After running for a little while, it was over 1000MB of RAM

This shows that ng serve keep using more RAM over time, as it keeps recompiling after each change. However, offhand I would guess that reducing this increase, is pretty far down the priority list of the CLI team!

[kylecordes]

I'm interested in whether anyone plays with this, with various settings, modes (-prod ?), platforms (windows linux mac) etc.

[TheLarkInn]

@kylecordes I believe that this could be related to webpack-dev-server but I'm not 100% sure where to look specifically. One thing that comes to mind is that in situations where webpack is running in its dev server, everything compiled is cached because it is an in-memory file system. So any convention that is using a hash in its name is going to be stored in memory until the end of time. See this explanation here.

So I think the first thing I will need to do is find instances of us in our codebase using the webpack [hash], [chunkhash], or [id] properties inside of our filenames for the ng serve and default --target='production' target.

[TheLarkInn]

I think that if this is happening on just plain default ng serve this is definitely a bug, however it is essentially unavoidable in --prod target.

We separated the idea of --prod and --dev targets but made them agnostic to and unmodifiedng serve task/command so people would have a more realistic local production experience.

I think in terms of --prod we need to simply document the long term use affects.

[TheLarkInn]

@slubowsky @kylecordes I did a little hands on memory profiling and heapshot analysis. (I couldn't do it locally so @hansl helped me).

Long story short things were either pointing towards the Compilation or some TS Services retaining some objects after Garbage collection was occuring.

Luckily we just merged in a kind contribution in webpack that fixes a V8 bug causing memory leaks in the webpack compilation. I believe that this is what is causing the issue, however I think it warrents still following up after we cut a release (on the webpack team), and update it here.

https://github.com/webpack/webpack/pull/2497/files

[kylecordes]

@TheLarkInn Thanks, sounds good. I will repeat the tests I described earlier in the thread, when the next new release comes out... or for that matter anyone else could try it also.

[mithun-daa]

Any word on this? I just migrated from beta.10 to beta.15 and I am unable to ng build. Get a similar error.

70% building modules 1345/1345 modules 0 active
<--- Last few GCs --->

  317945 ms: Mark-sweep 703.9 (837.9) -> 701.4 (811.9) MB, 331.3 / 0 ms [allocation failure] [GC in old space requested].
  318296 ms: Mark-sweep 701.4 (811.9) -> 701.4 (790.9) MB, 350.5 / 0 ms [allocation failure] [GC in old space requested].
  318730 ms: Mark-sweep 701.4 (790.9) -> 698.0 (760.9) MB, 433.7 / 0 ms [last resort gc].
  319058 ms: Mark-sweep 698.0 (760.9) -> 692.7 (751.9) MB, 328.7 / 0 ms [last resort gc].

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 00000298510373A9 <JS Object>
    1: /* anonymous */(aka /* anonymous */) [D:\dev\cobalt_wp\node_modules\webpack\lib\FlagDependencyExportsPlugin.js:77] [pc=0000026F721B51D6] (this=0000029851004131 <undefined>,dep=00000150FC6162C9 <a NormalModule with map 0000025741730C01>)
    2: arguments adaptor frame: 3->1
    3: InnerArrayForEach(aka InnerArrayForEach) [native array.js:~924] [pc=0000026F71EE3DCD] (this=000002985100413...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory

Not sure if this has anything to do with it but I also got the following error while npm i process-nextick-args util-deprecate (https://github.com/angular/angular-cli/issues/1930)

> node-zopfli@1.4.0 install D:\dev\cobalt_wp\node_modules\node-zopfli
> node-pre-gyp install --fallback-to-build

node-pre-gyp ERR! Tried to download: https://node-zopfli.s3.amazonaws.com/Release/zopfli-v1.4.0-node-v46-win32-x64.tar.gz
node-pre-gyp ERR! Pre-built binaries not found for node-zopfli@1.4.0 and node@4.2.3 (node-v46 ABI) (falling back to source compile with node-gyp)
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
TRACKER : error TRK0005: Failed to locate: "CL.exe". The system cannot find the file specified. [D:\dev\cobalt_wp\node_modules\node-z opfli\build\zopfli.vcxproj]

gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (D:\dev\cobalt_wp\node_modules\node-gyp\lib\build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:87:13)
gyp ERR! stack     at ChildProcess.emit (events.js:172:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)
gyp ERR! System Windows_NT 10.0.14393
gyp ERR! command "C:\\Program Files (x86)\\Nodist\\v-x64\\nodev4.2.3\\node.exe" "D:\\dev\\cobalt_wp\\node_modules\\node-gyp\\bin\\node-gyp.js" "build" "--fallback-to-build" "--module=D:\\dev\\cobalt_wp\\node_modules\\node-zopfli\\lib\\binding\\node-v46-win32-x64\\zopfli.node" "--module_name=zopfli" "--module_path=D:\\dev\\cobalt_wp\\node_modules\\node-zopfli\\lib\\binding\\node-v46-win32-x64"
gyp ERR! cwd D:\dev\cobalt_wp\node_modules\node-zopfli
gyp ERR! node -v v4.2.3
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok
node-pre-gyp ERR! build error
node-pre-gyp ERR! stack Error: Failed to execute 'C:\Program Files (x86)\Nodist\v-x64\nodev4.2.3\node.exe D:\dev\cobalt_wp\node_modules\node-gyp\bin\node-gyp.js build --fallback-to-build --module=D:\dev\cobalt_wp\node_modules\node-zopfli\lib\binding\node-v46-win32-x64\zopfli.node --module_name=zopfli --module_path=D:\dev\cobalt_wp\node_modules\node-zopfli\lib\binding\node-v46-win32-x64' (1)
node-pre-gyp ERR! stack     at ChildProcess.<anonymous> (D:\dev\cobalt_wp\node_modules\node-pre-gyp\lib\util\compile.js:83:29)
node-pre-gyp ERR! stack     at emitTwo (events.js:87:13)
node-pre-gyp ERR! stack     at ChildProcess.emit (events.js:172:7)
node-pre-gyp ERR! stack     at maybeClose (internal/child_process.js:818:16)
node-pre-gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
node-pre-gyp ERR! System Windows_NT 10.0.14393
node-pre-gyp ERR! command "C:\\Program Files (x86)\\Nodist\\v-x64\\nodev4.2.3\\node.exe" "D:\\dev\\cobalt_wp\\node_modules\\node-pre-gyp\\bin\\node-pre-gyp" "install" "--fallback-to-build"
node-pre-gyp ERR! cwd D:\dev\cobalt_wp\node_modules\node-zopfli
node-pre-gyp ERR! node -v v4.2.3
node-pre-gyp ERR! node-pre-gyp -v v0.6.30
node-pre-gyp ERR! not ok
Failed to execute 'C:\Program Files (x86)\Nodist\v-x64\nodev4.2.3\node.exe D:\dev\cobalt_wp\node_modules\node-gyp\bin\node-gyp.js build --fallback-to-build --module=D:\dev\cobalt_wp\node_modules\node-zopfli\lib\binding\node-v46-win32-x64\zopfli.node --module_name=zopfli --module_path=D:\dev\cobalt_wp\node_modules\node-zopfli\lib\binding\node-v46-win32-x64' (1)
npm WARN install:node-zopfli@1.4.0 node-zopfli@1.4.0 install: `node-pre-gyp install --fallback-to-build`
npm WARN install:node-zopfli@1.4.0 Exit status 1
cobalt-wp@0.0.0 D:\dev\cobalt_wp
├─┬ angular-cli@1.0.0-beta.15
│ └─┬ ember-cli@2.5.0
│   └─┬ npm@2.14.21
│     ├─┬ npm-registry-client@7.0.9
│     │ └─┬ concat-stream@1.5.1
│     │   └─┬ readable-stream@2.0.4
│     │     └── util-deprecate@1.0.2
│     └─┬ request@2.69.0
│       └─┬ bl@1.0.2
│         └─┬ readable-stream@2.0.5
│           └── util-deprecate@1.0.2
├── process-nextick-args@1.0.7
└── util-deprecate@1.0.2

I am on node 4.x and unable to proceed.

[mithun-daa]

@TheLarkInn @kylecordes @hansl Any help would be appreciated.

[kylecordes]

@mithun-daa We have a team of people using CLI-webpack-edition here, and have helped numerous others get it up and running. We have noticed that it consumes quite a bit of memory which grows over time - the topic of this issue, but when we run on good development hardware it is very little practical problem. We just end up restarting CLI every couple of hours, no big deal. I think maybe the error you experience might be unrelated to the general issue here of leakage over time. A quick way to check and help provide more information for the CLI team to work from, is to simply try the exact same thing again on a machine with abundant RAM.

[mithun-daa]

@kylecordes I wouldn't call my dev machine weak. These specs, I guess should be good enough:

[kylecordes]

Right, that is obviously more than ample RAM. So I don't think the problem you are experiencing has anything to do with the somewhat exaggerated RAM usage and leakage over time that CLI+webpack currently experiences. I think you there some other problem in your project.

I suggest making a copy of your project, then incrementally trim away nearly all of it until you have a minimum reproduction case for the failure, something which you can publish to a public repository. That will then be a solid bug report which it is likely someone could reproduce and fix. Or you might find that by trimming away pieces you eventually find the bit which triggers this problem, also a great outcome. Good luck.

[hansl]

@mithun-daa You can raise the heap size usingnode --max_old_space_size=2048 ./node_modules/.bin/ng build. We (and the webpack team) are aware of some memory problems and @TheLarkInn is the one looking into it.

[mithun-daa]

@hansl will this work on Windows? Get the following error:

case `uname` in
^^^^

SyntaxError: Unexpected token case
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:414:25)
    at Object.Module._extensions..js (module.js:442:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
    at Function.Module.runMain (module.js:467:10)
    at startup (node.js:136:18)
    at node.js:963:3

[hansl]

@mithun-daa Oh on windows you have to replace node_modules/.bin/ng by node_modules\.bin\ng :)

[mithun-daa]

i did try with the \ instead of / with the same results.

[hansl]

mmmh, then I'm not sure. It seems like this is a problem with Node that using a full path doesn't work. On my VM using node node_modules\.bin\ng does not work.

[mithun-daa]

Are there any prereqs? I am on Node 4.2.3. The global version of TS is different from the local version.

[hansl]

Not really. Node 4.2 should work. I'm seeing a different error on my side but similar reason, with Node 6 on Windows 10.

[mithun-daa]

@hansl If i create a new project using ng new everything works fine. but my existing app is massive and would like to avoid starting from scratch. I followed the directions in the Upgrade docs (beta.10 - beta.15).

[hansl]

Yes, I think the problem is the size of the app. We have that problem for one of our own as well, and there's no solution right now rather than just decrease the number of modules and/or components.

[mithun-daa]

ok. Not sure if this helps but it always crashes at the same point:

70% building modules 1345/1345 modules 0 active

[mithun-daa]

@hansl Are you guys still running out of memory on large apps? Wanted to check if the recent release fixed it.

[naveedahmed1]

Is it related to https://github.com/angular/angular/issues/12184 ?

[iwoogy]

Hello,

I have this out of memory problem too.

If I restart ng serve it loads but at the next code update, the error kicks in.

I start having this problem with the recent increase in the complexity of the project.

Anyone has an idea how to increase the memory on node ?

Thanks

Here is the log :

webpack: bundle is now INVALID. 5539ms building modules 18ms sealing 0ms optimizing 0ms basic module optimization 154ms module optimization 1ms advanced module optimization 10ms basic chunk optimization 0ms chunk optimization 0ms advanced chunk optimization 34ms module and chunk tree optimization 183ms module reviving 8ms module order optimization 6ms module id optimization 12ms chunk reviving 2ms chunk order optimization 43ms chunk id optimization 143ms hashing 2ms module assets processing 191ms chunk assets processing 9ms additional chunk assets processing 0ms recording 0ms additional asset processing 92% chunk asset optimization <--- Last few GCs --->

1051696 ms: Mark-sweep 1337.9 (1438.7) -> 1334.6 (1438.7) MB, 1522.6 / 0 ms [allocation failure] [GC in old space requested]. 1053315 ms: Mark-sweep 1334.6 (1438.7) -> 1334.5 (1438.7) MB, 1619.3 / 0 ms [allocation failure] [GC in old space requested]. 1054939 ms: Mark-sweep 1334.5 (1438.7) -> 1333.7 (1438.7) MB, 1623.8 / 0 ms [last resort gc]. 1056597 ms: Mark-sweep 1333.7 (1438.7) -> 1333.7 (1438.7) MB, 1657.3 / 0 ms [last resort gc].

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x3b457ffc9e59 2: addMapping(aka SourceMapGenerator_addMapping) [/(project_path)/node_modules/webpack-sources/node_modules/source-map/lib/source-map-generator.js:~94] [pc=0x13ba155d6c36](this=0x18debb29c861 <a SourceMapGenerator with map 0xe2aa00ac331>,aArgs=0x14fb4d43c101 <an Object with map 0xe2aa00abf69) 3: /* anonymous */ [/(project_path)/cli...

FATAL ERROR: CALL_AND_RETRYLAST Allocation failed - JavaScript heap out of memory 1: node::Abort() [/usr/local/bin/node] 2: node::FatalException(v8::Isolate, v8::Localv8::Value, v8::Localv8::Message) [/usr/local/bin/node] 3: v8::internal::V8::FatalProcessOutOfMemory(char const_, bool) [/usr/local/bin/node] 4: v8::internal::Factory::NewUninitializedFixedArray(int) [/usr/local/bin/node] 5: v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedObjectElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)2> >::ConvertElementsWithCapacity(v8::internal::Handlev8::internal::JSObject, v8::internal::Handlev8::internal::FixedArrayBase, v8::internal::ElementsKind, unsigned int, unsigned int, unsigned int, int) [/usr/local/bin/node] 6: v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedObjectElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)2> >::GrowCapacityAndConvertImpl(v8::internal::Handlev8::internal::JSObject, unsigned int) [/usr/local/bin/node] 7: v8::internal::RuntimeGrowArrayElements(int, v8::internal::Object*, v8::internal::Isolate_) [/usr/local/bin/node] 8: 0x13ba0f606338 Abort trap: 6

[naveedahmed1]

Are you using AoT?

[iwoogy]

I think I'm not.

I just use : ng serve without arguments.

I'm pretty new at this, so any explanation on how aot can help would be great.

[mithun-daa]

I don't use AoT either. I run out of memory on ng build or ng serve

[iwoogy]

It's on ng serve. ng build works fine.

[naveedahmed1]

Probably its due to the ngc, have a look at https://github.com/angular/angular-cli/issues/2981

Though you have mentioned you are not using AoT, but I still think the issue is with ngc if crashes for large projects.

[iwoogy]

Is there a way to fix it ?

[iwoogy]

I found this article : Increasing Node.js memory limits

Is there a way to pass this argument (---max_old_space_size) to angular cli ?

[singhjusraj]

I don't use angular-cli but I was able to fix the node.js memory limit issue for ngc Look at the answer here

[naveedahmed1]

@SinghSukhdeep that could be a workaround but not a permanent solution. and that only works on mac machine. And as you have mentioned you had to increase memory up to 8GB that might not be possible for many people.

[singhjusraj]

Sure yes, it is nowhere a permanent solution. It is just a workaround to keep development moving for the time being until ngc gets better at memory management. We all have to apply workarounds all the time till things get better.

[iwoogy]

Ok thanks for your answer.

By calling node directly this parameter --max-old-space-size=8192 solve the problem.

I'm using ng serve so is there a way to do like ng serve --max-old-space-size=8192 ?

Each time I change a file in the project the ng serve daemon crashed with OOM error.

I have to start ng serve again after each change.

The projet is not slowing down a bit, I'm a afraid that some day soon I won't be able even to start ng serve.

Any ideas guys how I can pass this parameter --max-old-space-size=8192 to ng serve ?

[mithun-daa]

I would guess that adding max-old-space-size to the system environment variables would do it - on Windows that is.

[naveedahmed1]

I added max-old-space-size in system environment variables and increased value to 6144 but when I compile my project which uses lazy loading using latest version of angular cli (ng build --prod --aot) it fails with "JavaScript heap out of memory " error..

I am using:

angular-cli: 1.0.0-beta.20-4
node: 6.9.1
os: win32 x64

Below is the log:

D:\MyProject>ng build --prod --aot
312982ms building modules
508ms sealing
16ms optimizing
1ms basic module optimization
299ms module optimization
5468ms advanced module optimization
136ms basic chunk optimization
0ms chunk optimization
21ms advanced chunk optimization
455ms building modules
1ms module and chunk tree optimization
1050ms module reviving
18ms module order optimization
48ms module id optimization
10ms chunk reviving
3ms chunk order optimization
44ms chunk id optimization
11288ms hashing
2ms module assets processing
1053ms chunk assets processing
9ms additional chunk assets processing
1ms recording
 91% additional asset processing
<--- Last few GCs --->

  680083 ms: Mark-sweep 1341.3 (1437.0) -> 1339.8 (1437.0) MB, 991.9 / 0.0 ms [allocation failure] [GC in old space requested].
  681044 ms: Mark-sweep 1339.8 (1437.0) -> 1339.8 (1437.0) MB, 960.9 / 0.0 ms [allocation failure] [GC in old space requested].
  682011 ms: Mark-sweep 1339.8 (1437.0) -> 1340.9 (1412.0) MB, 966.0 / 0.0 ms [last resort gc].
  682986 ms: Mark-sweep 1340.9 (1412.0) -> 1342.1 (1412.0) MB, 974.9 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0000019861ECFB61 <JS Object>
    1: /* anonymous */ [D:\MyProject\node_modules\webpack-sources\node_modules\source-map\lib\source-map-consumer.js:~142] [pc=000000411A16D6AE] (this=00000294368EDB49 <a BasicSourceMapConsumer with map 000003BC1D766499>,mapping=0000039E0356A939 <a Mapping with map 000003BC1D766C29>)
    2: arguments adaptor frame: 3->1
    3: map [native array.js:~994] [pc=000000411A15B70C] (thi...

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

[iwoogy]

Ok the time has come.

I cannot build the project anymore.

I restarted my computer with 16GB of RAM, and the project got to a point that compiling is not possible.

Please help...

Here is the log :

40239ms building modules 25ms sealing 0ms optimizing 0ms basic module optimization 160ms module optimization 1ms advanced module optimization 11ms basic chunk optimization 0ms chunk optimization 0ms advanced chunk optimization 0ms module and chunk tree optimization 207ms module reviving 3ms module order optimization 6ms module id optimization 13ms chunk reviving 9ms chunk order optimization 49ms chunk id optimization 4389ms hashing 3ms module assets processing 333ms chunk assets processing 17ms additional chunk assets processing 0ms recording 91% additional asset processing <--- Last few GCs --->

121245 ms: Mark-sweep 1369.5 (1434.2) -> 1369.5 (1434.2) MB, 3483.5 / 0 ms [allocation failure] [GC in old space requested]. 124715 ms: Mark-sweep 1369.5 (1434.2) -> 1369.5 (1434.2) MB, 3470.0 / 0 ms [allocation failure] [GC in old space requested]. 128154 ms: Mark-sweep 1369.5 (1434.2) -> 1369.5 (1434.2) MB, 3439.0 / 0 ms [last resort gc]. 131678 ms: Mark-sweep 1369.5 (1434.2) -> 1369.4 (1434.2) MB, 3523.9 / 0 ms [last resort gc].

<--- JS stacktrace --->

==== JS stack trace =========================================

2: arguments adaptor frame: 2->3

Security context: 0x2b4cb30c9e59 3: input(aka next_token) [0x2b4cb3004189 :~1903] [pc=0x2d76545c6849](this=0x2f0fc1b4f169 <an Object with map 0x357947bce511>,forceregexp=0x2b4cb3004189 <undefined) 4: arguments adaptor frame: 0->1 5: /* anonymous /(aka /_ anonymous */) [0x2b4cb3004189 :~2151] [pc=0x2d76545effaa](this=0x2b4cb3004189 <undefined) 6: b...

FATAL ERROR: CALL_AND_RETRYLAST Allocation failed - JavaScript heap out of memory 1: node::Abort() [/usr/local/bin/node] 2: node::FatalException(v8::Isolate, v8::Localv8::Value, v8::Localv8::Message) [/usr/local/bin/node] 3: v8::internal::V8::FatalProcessOutOfMemory(char const, bool) [/usr/local/bin/node] 4: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) [/usr/local/bin/node] 5: v8::internal::TypeFeedbackVector::New(v8::internal::Isolate, v8::internal::Handlev8::internal::TypeFeedbackMetadata) [/usr/local/bin/node] 6: v8::internal::CompilationInfo::EnsureFeedbackVector() [/usr/local/bin/node] 7: v8::internal::FullCodeGenerator::MakeCode(v8::internal::CompilationInfo) [/usr/local/bin/node] 8: v8::internal::GenerateBaselineCode(v8::internal::CompilationInfo) [/usr/local/bin/node] 9: v8::internal::GetUnoptimizedCodeCommon(v8::internal::CompilationInfo_) [/usr/local/bin/node] 10: v8::internal::Compiler::GetLazyCode(v8::internal::Handlev8::internal::JSFunction) [/usr/local/bin/node] 11: v8::internal::RuntimeCompileLazy(int, v8::internal::Object*, v8::internal::Isolate_) [/usr/local/bin/node] 12: 0x2d765150961b 13: 0x2d7651531ed9

[kylecordes]

@iwoogy Can you write any approximate statistics on the size of your project? Number of files, number of lines of code, how many of the files or components, that kind of thing? I would like to generate a fake application (programmatically) that generates this failure mode.

[iwoogy]

Yes of course.

Do you have any tools that I can use to get the numbers you need ?

I read the all issue thread again and the post of @hansl helped me a lot.

This command : node --max_old_space_size=2048 ./node_modules/.bin/ng build was the one I was looking for.

I also use this syntax with ng serve and it does not crash anymore.

[kylecordes]

I think CLOC is the easy for this purpose:

https://github.com/AlDanial/cloc

"npm install -g cloc"

[iwoogy]

Ok this is the result :

[kylecordes]

Is that just your "src" directory? If you run it at the top of the project, it might (I don't know what filtering it does built-in) count all the stuff in node_modules, which are potentially much larger than your application.

[naveedahmed1]

In my case:

components: 188
directives: 3
services: 8
modules:109
pipes: 3
templates: 178

It doens't include node_modules.

Below are the other modules my project uses:

"@angular/material": "2.0.0-alpha.10",
"angular2-color-picker": "1.2.1",
"angular-2-dropdown-multiselect": "0.3.0",,
"ng2-charts": "1.4.1",
"ng2-ckeditor": "1.1.4",
"ng2-img-cropper": "0.7.1"

[iwoogy]

I ran cloc src

It does not include the node_modules.

[kylecordes]

@naveedahmed1 That does not appear to be a particularly large application, I'm surprised at the size that it is bumping into RAM limitations in the build. It had been my impression the boundary was quite a lot further out. (Unless maybe some of those components/services/etc. have a remarkably large amount of code in them.)

@iwoogy Yours appears to be a quite large Angular project, that is more the size range I would expect to react the limits of the tools. I think at this point in the development of CLI, you might possibly need to pick up a more customized set of build tooling to work at that scale.

The key mystery is: why was one of these two projects was able to get so much larger before running into limitations? There might be a clue in there that could help the team fix the problem.

[iwoogy]

Do you have any suggestions of the set of tools I should use for large projects ?

[mithun-daa]

Here are my numbers

This is only my angular code in the src dir

[kylecordes]

About the additional numbers: if this is another example of a not-all-that-big application running up against the limits, it could be useful to the CLI team when their attention is on this item. At the moment is marked as "priority 3 nice to have", but maybe one of them will have an update on it.

About the question of other tools: typically the advice I've been giving (I work at a company where we help big companies launch their Angular efforts with training etc.) is that if CLI does not meet your needs yet, go look at the several available "seed" projects, experiment with each, and see which one seems like the closest fit. I don't have a list handy as I write this, but there are quite a few out there. (I also always give you advice: CLI is getting better all the time, even if you need to stop something else for a while, come back later!)