react-scripts@2.0 takes forever to build

[lamngo255]

Recently, I upgraded a CRA project to the latest react-scripts v2 release (2.0.0-next.2150693d), and quickly realized that "yarn build" takes hours to build my project. Seems like it hangs at "Creating an optimized production build" for some reasons. That was quite unexpected since the previous version of react-scripts that I used (v1.1.5) could build the project just fine, though production build took a fairly long time (~15min).

FYI, before I was able to build, I had to manually update eslint to version 5.6.0, because react-scripts v2 requires it and a different version of eslint (3.9.1) detected higher up in the tree isn't compatible with react-scripts@2.0, sorta similar to this known issue. I guess this approach could prevent users from breaking react-scripts initial dev dependency? (link).

Environment

1. node -v: v8.12.0
2. npm -v: v6.4.1
3. yarn -v: (if you use Yarn): v1.9.4
4. react-scripts: (if you haven’t ejected): 2.0.0-next.2150693d
5. Ubuntu 16.04 LTS

Expected Behavior

yarn build succeeds

Actual Behavior

Get stuck at "Creating an optimized production build..." forever.

Reproducible Demo

Here's my package.json

[gaearon]

I don’t think rewires are compatible with 2.x. AFAIK that project is not actively maintained anymore either.

[lamngo255]

Unfortunately, removing any packages related to react-app-rewired and config-overrides.js didn't seem to work either. I've tried yarn build & yarn start but they both get stuck for hours.

[Timer]

Could you please share this project? Hours seems quite excessive ... how are production build times the second build (without removing node_modules)?

[lamngo255]

@Timer sorry, it's a private project, so I can't share it. Although I mentioned that it takes hours, in reality, I couldn't complete the production build. Because it takes over 3 hours stucking with "Creating an optimized..." message, so I just shut it down.

The normal build time was ~950s, for react-scripts v1.1.5 + react-app-rewired. If I were to remove rewire packages, I would end up getting this error, which I think was caused by insufficient optimization in react-scripts v1.
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

[Timer]

What is your rewired doing for you?

[Timer]

Please try running GENERATE_SOURCEMAP=false yarn build and see if that completes any faster.

[lamngo255]

I used rewired for uglifying and vendor splitting. Since react-scripts v1 seems to not support automatic vendor chunking without the latter library, I switched to react-scripts v2.0 to use webpack 4 features, including vendor splitting and terser (uglifyjs) plugin.

[Timer]

I would definitely remove your rewire then with v2, it might be causing some bad configuration.
Please try GENERATE_SOURCEMAP=false yarn build with no rewires applied.

Unfortunately, we're not going to be of much help unless if you can share the project with us privately.

[lamngo255]

Please try running GENERATE_SOURCEMAP=false yarn build and see if that completes any faster.

Thank @Timer, it's actually significantly faster when using react-scripts v1, down to ~600s. I'll try with react-scripts v2.

It's my company's project, so unfortunately, I don't think sharing the project would be a good idea.

[gaearon]

You can try completely disabling Terser by temporarily commenting it out in the config. This will tell you whether it’s webpack or Terser that hangs.

You can also try adding webpack’s built in ProfilerPlugin to trace its execution.

[lamngo255]

Funnily enough, it looked like I was able to build successfully with source map disabled and no wires applied (react-scripts@2.0). The build time was reduced to just ~348s, much faster than what I would've expected. However, there's much more sub 1KB chunk files produced during the process, which I believe will hurt the performance.

"yarn build" with source map enabled remains stuck, but let's see how long it will hang.

[lamngo255]

You can try completely disabling Terser by temporarily commenting it out in the config. This will tell you whether it’s webpack or Terser that hangs.

You can also try adding webpack’s built in ProfilerPlugin to trace its execution.

Interesting, but how could you enable those configurations in the webpack config file without even ejecting and no rewires? I tried editing webpack.config.prod.js in the node_modules, but I don't think this is a viable option, because the file remains intact whenever I rebuild the project.

[Timer]

Interesting, I'm happy to hear v2 is faster! Can you disable Terser and re-enable sourcemaps and see if the build completes?
I'm curious what part of the sourcemap pipeline is getting stuck.

To edit config, I suggest you commit all changes, eject, and then revert the eject when you're done testing.

[gaearon]

Sorry, I only meant to suggest editing as a temporary way to try to diagnose the issue. It wouldn’t persist indeed.