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

[prasanthkarukkuvel]

ts-loader runs out of memory while building. Its seems related to use of enhanced-resolve

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

Security context: 000002F1F9DC9E51
1: forEachBail [D:\Production\fsm-ui-analytics\node_modules\ts-loader\node_modules\enhanced-resolve\lib\forEachBail.js:~5] [pc=000003F65D84C023] (this=000002F1F9DE0D29 ,array=0000038750240011 <JS Array[7]>,iterator=0000038750240079 <JS Function (SharedFunctionInfo 0000006216543CD1)>,callback=00000387502400C1 <JS Function (SharedFunctionInfo 0000006216543D91)>)
2: /* ...`

But adding LoaderOptionsPlugin with options to webpack resolves this issue

new LoaderOptionsPlugin({ options: {} })

Might be because

function makeResolver(options: { resolve: interfaces.Resolve }): interfaces.ResolveSync { return node.create.sync(options.resolve); }

[johnnyreilly]

Thanks for sharing that. I'm wondering if this is related to #420 - seems likely.

[johnnyreilly]

I'm pondering whether adding loader options to when constructing the resolver might be a good idea.

[johnnyreilly]

BTW - which version of WebPack are you using? And can you confirm if the issue occurs when using ts-loader 1.3.1? We used an older version of enhanced-resolve then

[prasanthkarukkuvel]

@johnnyreilly I am on [email protected] rite now. With 1.3.1 its failing with TypeError: Cannot read property 'unsafeCache' of undefined without options in LoaderOptionsPlugin

[johnnyreilly]

Thanks @prasanthkarukkuvel - I'm not totally certain but I think having LoaderOptionsPlugin in play is pretty much mandatory for webpack 2. I'm asking for some guidance on this.

[shepmaster]

I am experiencing something similar when trying to upgrade ts-loader from 2.3.7 to 3.0.5. I'm using Webpack 3.8.1. If it's useful, you can grab the code and execute yarn build in the ui/frontend directory. I am using macOS (10.12.6) and Node v8.7.0. My computer has 16GB of RAM, and watching the memory usage of the node process, I only see it get to about 1.4GB. What's interesting is that I'm seeing the same behavior trying to upgrade TypeScript from version 2.4.x, but this is without that upgrade.

[shepmaster]

Perhaps there is a difference in how ts-loader 3.x decides which files to compile? It turns out that I have ~50 MB of files in my build directory and my build directory was not in the tsconfig.json's exclude key. That was causing these files to be compiled even though they aren't referenced from my entrypoint. Perhaps this is what #267 is intended to fix?

[johnnyreilly]

Don't know why anything we'd have done between 2.x and 3.x would make a difference. Curious..

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale. Please reopen if you'd like to work on this further.