Always, after multiple changes, a random number, webpack deletes all files and regenerate them, and since it's a slow process I want to avoid it, if possible.
This occurs after a FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - Javascript heap out of memory.
I was wondering if this could be solved or improved by docker configuration or similar since i think this is not a machine specs problem.
All team mates suffers it to a greater or lesser degree (It happends to me about once or twice per hour). But I in particular, can reproduce it on my machines:
- Ryzen 12 threads and 16GB ram with SSD storage. Ubuntu 19.10. docker 19.03.3, docker-compose 1.24.1, nodejs: 10.16.1
- Intel i7 12 threas and 20GB ram with SSD storage. Ubuntu 19.10. docker 19.03.3, docker-compose 1.24.1, nodejs: 10.16.1
I think this can pass unnotice if you're not seeing log all the time, or if you are used to save few times after many changes.
But we should take this into account since a normal webpack refresh is much, much, much faster than a full rebuild, and i think it's a time waster problem.
Updated:
After testing, I can solve this problem entering into fusion-webpack docker container and changing package.json to make build script launching node with --max_old_space_size parameter. And instead of make npx fusion rebuild, I just launch: docker stop fusion-webpack && docker start fusion-webpack.
Obviously the problem comes due to we destroy containers every day. So it'll be marvellous if could pass parameters to node from .env file in project.
Guest
As of CLI version 1.1.0 ENGINE_HEAP_SIZE and WEBPACK_HEAP_SIZE are now user configurable. See documentation at https://www.npmjs.com/package/@arc-fusion/cli/v/1.1.0
Working on Arc locally makes me sad. It takes so long to start up and consumes so much resources. The standard development experience on React is hot module reloading– that'd be really nice. I honestly feel like it takes me at least 2x as long to complete any feature on on Arc vs. with create-react-app.
We reported this similar issue to ACS over 3 months ago. It is a huge drag on our developers productivity and morale. Anything that can be done to speed up the development environment would be great. ACS tickets 7631 / 8014.
I've thinking about webpack memory leaks and the possibility of they're unrelated to ARC.
The scalability problem is there, and we all suffer it in our daily workflow.
So it would be great if fusion start command could be launched to --watch not all the folder hierarchy, since this process is the flow bottleneck, but only the current component which we are working on. So it'll be interesting if you add an optional parameter. e.g: npx fusion start "/components/chains/classified-chain"
Webpack has de watchOptions.ignored config property (it's a regex) to achieve that, maybe binding that to a fusion parameter will be enough... what do you think?
At the end of the day, 99% of the time we want to look for changes only in a couple of folders after initial build happended on the branch switching.
I’m happy to help
Thank you so much for the detailed response, your testing was very valuable. This is now planned work.
The slow process which I referred to is first webpack build, when fusion-webpack container is created. I don't know if it can be optimized or not, but this should be executed only once a day.
The problem I've tried to explain is this container is running node with its default memory limit, which is about 1.5GB.
After some time running, particulary if you save enought file changes in a short time, then the node garbage collector doesn't have time to free enought memory, so the process ends crashing due to exceeding the max memory limit, so fusion-webpack container is restarted and initial build process is launch again. Crashing can happen many times in few hours.
The solution is to run node with a higher memory limit (see --max_old_space_size option).
Also mentioning this problem affects others container, for example fusion-engine, but it's less remarkable since it reboots much faster than webpack one.
I'm suggesting to set higher node memory limit by default or even better: parametrize this limit to be taken from .env file.
This is a helpful use case to consider when we revisit our webpack strategy. Can you give us more information on what is slow? What is the expectation?