Create-react-app: Since updating to 3.3.0, running out of memory

[daviseford]

Describe the bug

After upgrading to 3.3.0 and TS 3.7.3 (was previously on 3.2.0 and TS 3.7.2), I am unable to run yarn start

I receive this error: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Reverting to react-scripts v3.2.0 resolves this issue - Typescript being at 3.7.3 or 3.7.2. has no effect, so I've narrowed it to react-scripts.

Did you try recovering your dependencies?

Yes, blew away node_modules and re-ran yarn, tried without a lock file, etc. No dice.

Environment

Windows 10, VSCode (also occurs on my macbook)

[endiliey]

You’ll need a reproducible repo for this. There are some dependencies upgrade in 3.3.0 and that could have taken more memory usage.

[xiaoxiangmoe]

I also encountered the same problem in the company project.

[anhquande]

me too

[daviseford]

I apologize because this isn't a minimally reproducible repo, but this is my repo having problems: https://github.com/daviseford/aos-reminders

Just running yarn, upgrading react-scripts to 3.3.0, and running yarn start will give you the bad behavior.

I will look into creating a minimal version after work.

[mrmckeb]

Have you tried removing the existing node_modules, then reinstalling? Maybe also removing the lockfile? Just out of interest.

[daviseford]

Yes to both.

[MasterCassim]

I had the same error with nodejs v10; upgrading to nodejs v12 fixed the issue for me.

[daviseford]

I am on v12.11.0

[xiaoxiangmoe]

I am on v13.2.0

[petetnt]

Temporary workaround is to set a larger max-old-space-size eg, react-scripts --expose-gc --max-old-space-size=8192 ... as stated in https://github.com/facebook/create-react-app/issues/8130#issue-535323604

[abrcdf1023]

Use @petetnt suggestion is work but it take a lot of build time.

[mcaubrey]

I experienced this today, however it was from updating from 3.0.1 to 3.2.0. After reverting to 3.0.1 the problem disappeared.

I'll attach the generated report.json file.
report.20191213.130235.34745.0.001.json.zip

[chawax]

Same problem here. I upgraded to react-scripts 3.3.0 and webpack 4.41.2 and I had this memory problem.

@petetnt suggestion did not help

Disabling sourcemaps generation solved the problem, but you need them when developing !

[robsco-git]

Please see https://github.com/wojtekmaj/react-pdf/issues/498#issuecomment-566948710 - a response to what I think may be the same issue. I am not sure how one fixes this within the context of create-react-app.

[astrada]

It looks like this issue: babel/babel#10875. That's fixed in https://github.com/babel/babel/releases/tag/v7.7.7. create-react-app should bump the @babel/core dependency.

[yusufnb]

Having this same issue since I upgraded react-scripts. Node version v13.1.0. react-scripts 3.3.0.

[gnmerritt]

The following in package.json fixed the issue for me (react-scripts 3.3.0, react-pdf) without requiring the memory increase flags:

  "devDependencies": {
    "@babel/core": "^7.7.7",

[benbruscella]

@gnmerritt this didn't work for us, anything else you changed?

[erik-sytnyk]

I've been able to run app changing npm start script

      "start": "react-scripts --max_old_space_size=4096 start",

[jacobwod]

The following in package.json fixed the issue for me (react-scripts 3.3.0, react-pdf) without requiring the memory increase flags:

  "devDependencies": {
    "@babel/core": "^7.7.7",

Adding "@babel/core": "^7.7.7", to devDependencies did work in my project, even though I didn't have explicit dependency to @bable/core previously in package.json.

There were (and still are) multiple dependencies to @bable/core in package-lock.json, of course. Intrestingly, those "dependencies of dependencies" still refer to 7.7.4 in package-lock.json. But the project starts and builds fine.

[beaulac]

If you're using yarn (npm doesn't support this natively unfortunately) you can use resolutions instead of devDependencies

"resolutions": {
  "@babel/core": "^7.7.7"
}

Using npm with devDependencies might not always work immediately since NPM is non-deterministic and the node_modules tree depends on the order of installation.

[jacobwod]

Thank you @beaulac, had no idea of resolutions, but after reading the docs it seems like a good reason to migrate to Yarn.

In the meantime I've downgraded to "react-scripts": "3.2.0", which uses an older "@babel/core" and starts/builds fine for me.

[Chnapy]

I have this issue with 3.3 AND 3.2 (I come from 2.1), with node v10.x.

Note that upgrading node to v12 solve this issue. edit nevermind it doesn't work either with node v12, it may be an issue relative to other deps of my project, but it appeared only since CRA 3.2.

[MatueszDev]

setting GENERATE_SOURCEMAP=false in .env work for me

[mehrdadgit]

If you don't want to migrate to yarn or downgrade to [email protected],

npm update @babel/core --depth 3

fixed the issue for me (Node v12.4.1)

[aquan9]

Same issue, Downgrading to [email protected] worked for me.

[mheavenor]

3.3.1 still exhibits the same behavior. Production build succeeds with GENERATE_SOURCEMAP=false but development build still broken 😢

[ianschmitz]

3.3.1 includes babel 7.8.4 which should include the fix on babel's side. Can anyone else confirm that 3.3.1 fixes the issue they were having previously?

[leclercb]

I still have the same out of memory issue with 3.3.1.
Only 3.2.0 works.

Btw, I have two similar projects, more or less the same size and dependencies, one was failing with the out of memory with 3.3.0, one was working.
With 3.3.1 both are now failing with the out of memory.
3.2.0 works for both.

[astrada]

Can anyone else confirm that 3.3.1 fixes the issue they were having previously?

It fixed it for me (I have pdfjs-dist among dependencies, that was causing the issue).

[Chnapy]

3.3.1 includes babel 7.8.4 which should include the fix on babel's side. Can anyone else confirm that 3.3.1 fixes the issue they were having previously?

It didn't change anything on my side :(

[FinnFrotscher]

+1

[RIP21]

@MatueszDev way worked for me. Still feels super hacky.
I'm on 3.3.1.
Waiting for a proper fix.

[RIP21]

Just to clarify. 3.4 the same thing, and it's supercritical cause it kills our error reporting because we don't upload source maps :(

[RIP21]

Wondering if anyone here that has this issue has graphql.macro or any kind of babel macro?
I think it may be connected to a memory leak.

I had a reusable module in my monorepo that has been using grpahql.macro that was importing huge GraphQL Schema, so the file gets like 40-50k LOC of GraphQL AST JSON inside, and any test or app that is based on CRA that was importing this library started to get out of memory error.
After, I isolated these functions, that are using macro, into a separate more specific module, all apps/test files that do not rely on this specific module, started to work just fine.
Before at 3.2.0, code was exactly the same and it all was good.

[ianschmitz]

If someone can provide a repository that can reproduce this problem it would be greatly appreciated and would help get this fixed faster. Thanks!

[xiaoxiangmoe]

https://github.com/xiaoxiangmoe/create-react-app-running-out-of-memory

@ianschmitz

If we change "react-scripts": "3.3.0" to "react-scripts": "3.4.0", the error will disappear.

[lk-jeffpeck]

I found this to happen in dotenvi when I have a string with { curly brackets } in my yaml file. I am not sure of a good workaround though. And I'm not sure if it's related.

[RIP21]

BTW. Disabling of the sourcemaps doesn't work in 100% so this issue is impossible to fix temporarily by its disabling.
Usually, it's all good on CI, when fresh installs, but when people start to do some changes or adding some dependencies eventually it stops working with OOM.
Maybe symlinks can be in effect here? We're using rush.js monorepo solution which is heavy on them.

[RIP21]

Another hypothesis comes from relative and absolute imports.

import { setLocalStorage } from ‘helpers/utils’

kills watch more for people
While making it

import { setLocalStorage } from ‘../../helpers/utils’ 

Makes it all working.
Also somehow changing from INLINE_RUNTIME_CHUNK=false to true help people sometimes.

Also, we're having out of memory in tests, like each of it fails with OOM from time to time.
Feels like complete random info, but I try to get to give some clue, so at least there is some small chance to find it and fix somehow... I assume Babel is still to blame.

[sxqnicholas96]

If you don't want to migrate to yarn or downgrade to [email protected],

npm update @babel/core --depth 3

fixed the issue for me (Node v12.4.1)

Can confirm this worked for me! (Node v12.14.0)

[lamqson]

https://github.com/xiaoxiangmoe/create-react-app-running-out-of-memory

@ianschmitz

If we change "react-scripts": "3.3.0" to "react-scripts": "3.4.0", the error will disappear.

It is still happening in 3.4.0

[ARMATAV]

Ran into this after;

yarn add pdfjs-dist @types/pdfjs-dist

Resolved with;

"resolutions": {
    "@babel/core": "^7.7.7"
},

And no other changes.

[Chnapy]

Hi,

Just referencing these material-ui related issues:

• https://github.com/microsoft/TypeScript/issues/34801
• https://github.com/mui-org/material-ui/issues/19113

My project, which have this memory issue, is using material-ui, so maybe there is a link between this issue and these.

For people who is in my case, you can try to remove material-ui type checking in your project to see if there is any change by doing this tip: https://github.com/mui-org/material-ui/issues/19113#issuecomment-592797820
I didn't try myself yet.

[FinnFrotscher]

I dont use material ui and still have this issue

[buncis]

I also got the error with new project npx create-react-app and installing plotly

adding the memory flag to start scripts fixing the issue

"start": "react-scripts --max_old_space_size=4096 start",

my package.json

{
  "name": "plot.ly",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@testing-library/jest-dom": "^4.2.4",
    "@testing-library/react": "^9.3.2",
    "@testing-library/user-event": "^7.1.2",
    "plotly.js": "^1.52.3",
    "react": "^16.13.1",
    "react-dom": "^16.13.1",
    "react-plotly.js": "^2.4.0",
    "react-scripts": "3.4.1"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": "react-app"
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

[luminaxster]

Thank you so much @petetnt, @yegor-sytnyk, and @buncismamen, I had the same error using build and adding max_old_space_size fixed it:
"build": "react-scripts --max_old_space_size=4096 build"
I know is just a hot-fix, but I take it meanwhile.

[ARMATAV]

Error reappears when building for production through rescripts build pipeline.

...Even _after_ removing pdfjs-dist.

[lamqson]

Just tried with v3.4.1. It is still failing. I include here the crash report just in case:

report.20200328.113538.43465.0.001.txt

And when I turn off source map generation: export GENERATE_SOURCEMAP=false, it works fine. But we really need to have source-map turned on though.

Thanks.

[JGeiser9]

I still have the same out of memory issue with 3.3.1.
Only 3.2.0 works.

Btw, I have two similar projects, more or less the same size and dependencies, one was failing with the out of memory with 3.3.0, one was working.
With 3.3.1 both are now failing with the out of memory.
3.2.0 works for both.

Had to revert and pin my package.json to 3.2.0 to avoid heap memory issues as well

[FinnFrotscher]

any update?

[Chnapy]

As said here https://github.com/facebook/create-react-app/issues/8676#issuecomment-609080382 it would be interesting to know if people who have this issue is in JS or TS context, because of the presence or not of type-checking (via ForkTsCheckerWebpackPlugin) and its memory limit that cannot be change in CRA.

In my case we're using Typescript, the build fails during the type-checking by ForkTsCheckerWebpackPlugin no matter how many we put as memoryLimit.

If only TS projects are concerned, it may be a Typescript and/or ForkTsCheckerWebpackPlugin issue.

[segulino]

@Chnapy In my case is a JS context.

[tobias-tengler]

@Chnapy we do use Typescript.

[duhseekoh]

We have a pretty large typescript CRA. After upgrading we ran into this. Using node v12 fixed it for us, but I'm guessing there is still an underlying issue in CRA.

[ellis]

@Chnapy I'm having the problem with typescript

[PaulPCIO]

the same problem, with a typescript setup

[yeion7]

Javascript setup here

[liuxinqiong]

I have the same problem. Hope to be resolved!

[liuxinqiong]

tried some ways above, update react-scripts to 3.4.1, that didn't work for me. but update @babel/core worked for me. I just run npm install @babel/core --save-dev script, by the way, the installed @babel/core version is 7.9.0.

[sbuljac]

Updating `@babel/core' to the latest version didn't help in my case.

[VehpuS]

I found a workaround (that I would love to add as a pull request if none is planned) - skipping TS typechecking during the build stage for the project. This was useful as a way to unblock my project when it started exhibiting this behavior on build.

I managed to do this by manually editing node_modules/react-scripts/config/webpack.config.js to comment out the type checking section:

      // TypeScript type checking
      //   useTypeScript &&
      //     new ForkTsCheckerWebpackPlugin({
      //       typescript: resolve.sync('typescript', {
      //         basedir: paths.appNodeModules,
      //       }),
      //       async: isEnvDevelopment,
      //       useTypescriptIncrementalApi: true,
      //       checkSyntacticErrors: true,
      //       resolveModuleNameModule: process.versions.pnp
      //         ? `${__dirname}/pnpTs.js`
      //         : undefined,
      //       resolveTypeReferenceDirectiveModule: process.versions.pnp
      //         ? `${__dirname}/pnpTs.js`
      //         : undefined,
      //       tsconfig: paths.appTsConfig,
      //       reportFiles: [
      //         '**',
      //         '!**/__tests__/**',
      //         '!**/?(*.)(spec|test).*',
      //         '!**/src/setupProxy.*',
      //         '!**/src/setupTests.*',
      //       ],
      //       silent: true,
      //       // The formatter is invoked directly in WebpackDevServerUtils during development
      //       formatter: isEnvProduction ? typescriptFormatter : undefined,
      //     }),

I would like to have this option as a compilation flag, since it also reduces compilation time and can therefore be a useful tool in some scenarios.

[tobias-tengler]

@VehpuS IMO disabling type checking during build, even if it is hidden behind a flag, defeats the purpose of using Typescript.
Also, since your workaround is editing node_modules manually, it will not be a good fit for people who (hopefully) have not checked in their node_modules and use proper CI builds.

This issue is likely caused by an underlying performance/compatibility problem and should therefor be directly addressed and fixed in an upcoming version.

[VehpuS]

@VehpuS IMO disabling type checking during build, even if it is hidden behind a flag, defeats the purpose of using Typescript.
Also, since your workaround is editing node_modules manually, it will not be a good fit for people who (hopefully) have not checked in their node_modules and use proper CI builds.

This issue is likely caused by an underlying performance/compatibility problem and should therefor be directly addressed and fixed in an upcoming version.

I understand what you're saying, but respectively - I disagree.

This error is not specific to a single issue - it describes a memory overflow that can occur in many cases, at least if the various reports on such issues being discussed is an indication of it (google searches I've made for it, beyond the long discussion here, yield several results). I hope it will be addressed but it is not something that has a bearing on the code running, and it is very useful to be able to continue developing despite a type checking issue.

As for this defeating the purpose of typescript - I personally find that even limiting myself to vscode's runtime type checking in a file is more than a reason enough to use typescript, not to mention that this is intended as a debugging / workaround flag.

Finally, I obviously didn't intend to suggest my workaround is useful for everyone, but from personal experience it has allowed me to continue running production builds of a personal project locally (which is where node_modules editing works find, even if it is not persisted) without being stuck in debugging an essentially devops issue, which is not the most important to me at the moment. Since I personally found it useful - I suggested it here :).

[yeion7]

I did some profiling using cpuprofile-webpack-plugin on my project where I have this issue, these are the results

react-scripts 3.2.0

it took 47s to built the project

react-scripts 3.4.1

it tool 150s to build the same project, 3x slower, and it seems eslint-loader required more resources

react-scripts 3.4.1 disabling eslint

for this test I disabled eslint then the build took 56s

[JosNun]

Fwiw, UI had this same issue and fixed it by nuking my node modules and reinstalling

Also, using typescript & react-scripts 3.4.1

[waynebrantley]

• Can confirm anything after 3.2.0 runs out of memory building on CI server.
• limited success with --max-old-space-size=8192
• Sometimes seems to succeed - about 20% of the time - so a bit intermittent (on appveyor). Machine has 6GB ram.
• Can confirm disabling sourcemaps fixes the problem completely (do not use pdf.js)
• @yeion7 That is great. Added a eslintignore in the root before running CI build and build times are 2-3 times faster! Am using typescript, so that is still running and eslint is still enabled at development time.

So now I am able to upgrade, but now do not have sourcemaps for errors and such.

[ellis]

@waynebrantley Could you explain how you used eslintignore in more detail, such as what contents you put in it to achieve the 2-3 times speed increase?

[waynebrantley]

@ellis I retract my statement. During all these issues, appveyor had allocated a machine with lots of ram and super fast to help figure this out. This happened when I made the above change and did not realize it! What I was doing was creating an .eslintignore file and putting a * in it.

[jdwilkin]

I am seeing this problem as well... any updates?

[Relaxe111]

I have similar issue described here. Maybe these issues are related?

[mattjcj]

I had an issue that might be related to this, so I'm posting in case anyone encounters this. I wasn't getting any node error, but my CI pipelines running "npm run build" on Bitbucket kept running out of the 3GB of memory allocated. I was running 3.4.1 and downgrading to 3.3.1 fixed it for me.

[ALEUT]

Duplicated my comment here:
Have the same problem, my build is failed because of old version of fork-ts-checker-webpack-plugin. After forcing use the latest version (4.1.3) everything compiles successfully (but if there is any error - I see the exception because error processing is incompatible with 4x version). Before I tried to play with memory (increase it for the plugin) - but it didn't help: it eat all the given memory (even 8g). So it looks there is some bug in the version, which is current in CRA (3.1.1).

[BudickDa]

I had the same problem using Typescript 3.9.2 and it happened when I imported a function that used a redux store into a file that was imported from a .js file as a worker with workerize-loader.
(yes this is a weird thing to do, I had my reasons...)

I have a function log(message:any)=>void that is used everywhere in my application to log messages by dispatching _addMessage to a redux store.

The function log that dispatches the action looks like this:
export function log(message: any) { store.dispatch(_addLog("FOO", "INFO")); //I use JSON.stringify(message) instead of "FOO" but I want to keep it as simple as possible return; }

Now this is where the error showed:
I used the function log to show an error message if the firebase config was wrong. My worker uses firebase to do stuff to the database, thus it imports my firebase class with the firebase config.

Now there are two things that could go wrong:

1. My worker is imported like this in a file called index.js (because CRA doesn't support web-workers):
   import UserResolver from 'workerize-loader!./UserResolver.worker'; // eslint-disable-line import/no-webpack-loader-syntax export default { UserResolver }
   If you having this error and using JavaScript and TypeScript maybe this is a place to start looking.

1. The worker has only comlink and firebase as dependencies. It also imports a class that initializes firebase and some interfaces. By using log it imports the whole redux stuff, maybe this is where the compiler goes bye bye.

I hope this helps. Good luck!

[rhuanbarreto]

Just confirming that npm update @babel/core --depth 3 fix proposed by @mehrdadgit is working fine on latest version of react-scripts (3.4.1) for me.

--max-old-space-size=8192 is not supported by most of the CI's and will make the build fail once npm run build start due to memory limitations. We use docker hub for building the frontend images and the limit is 3GB.

Also, build time went from 28 to 10 minutes. It's a huge improvement!

A bump in @babel/core can simply fix the problem.

[BudickDa]

I tried
"resolutions": { "@babel/core": "7.9.6" } and
"devDependencies": { "@babel/core": "^7.9.6" } in package.json.

Both did not solve my problem.

It still crashes as soon as I import something from the main thread into the worker or vice versa.
(Also if I import something, that imports something, that cannot be accessed).

Detailed error message:

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

0: ExitFrame [pc: 000000B86A4DC5C1]
1: StubFrame [pc: 000000B86A48D64B]
2: ConstructFrame [pc: 000000B86A48D1E3]
3: StubFrame [pc: 000000B86A509DFD]
Security context: 0x03af9be9e6e9
4: /* anonymous /(aka / anonymous */) [00000023F27F17A1] [C:\Users\user\WebstormProjects\projectnode_modules\webpack\lib\Parser.js:547] [bytecode=00000179
36A48069 offset=134](this=0x00b32fe026f1 ,expr=0x...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF69115832A v8::internal::GCIdleTimeHandler::GCIdleTimeHandler+4506
2: 00007FF691132DB6 node::MakeCallback+4534
3: 00007FF691133730 node_module_register+2032
4: 00007FF69144C14E v8::internal::FatalProcessOutOfMemory+846
5: 00007FF69144C07F v8::internal::FatalProcessOutOfMemory+639
6: 00007FF691632874 v8::internal::Heap::MaxHeapGrowingFactor+9620
7: 00007FF691629856 v8::internal::ScavengeJob::operator=+24550
8: 00007FF691627EAC v8::internal::ScavengeJob::operator=+17980
9: 00007FF691630BF7 v8::internal::Heap::MaxHeapGrowingFactor+2327
10: 00007FF691630C76 v8::internal::Heap::MaxHeapGrowingFactor+2454
11: 00007FF69175AF17 v8::internal::Factory::NewFillerObject+55
12: 00007FF6917D8106 v8::internal::operator<<+73494
13: 000000B86A4DC5C1
error Command failed with exit code 134.

[rhuanbarreto]

@BudickDa your issue is very specific and deals with workers and other stuff that a simple CRA user doesn't experience. In our case we don't have workers, and advanced type of implementation and we were having problems when you do npm run build.

Maybe you should ask your question in webpack library. 😉

[mihaipanait]

disabling source maps for production build did the trick for me

"scripts": {
   ...
   "cibuild": "CI=true GENERATE_SOURCEMAP=false react-scripts build"
}

downgrading/upgrading package versions made it worse in some cases (more memory needed)

[ALEUT]

disabling source maps for production build did the trick for me

"scripts": {
   ...
   "cibuild": "CI=true GENERATE_SOURCEMAP=false react-scripts build"
}

downgrading/upgrading package versions made it worse in some cases (more memory needed)

You can put these parameters to .env.production file.

[BudickDa]

@BudickDa your issue is very specific and deals with workers and other stuff that a simple CRA user doesn't experience. In our case we don't have workers, and advanced type of implementation and we were having problems when you do npm run build.

Maybe you should ask your question in webpack library. 😉

I already know the reason for my problem. It happens, when I import between "different worlds".
It should not run out of memory tho. This means there is something wrong.

I posted this for two reasons:

1. Maybe someone who has the same problem has uses webworkers stumbles upon this issue and it helps them.
2. Maybe the memory issue is caused by the same bug and can be provoked by importing things, that cannot be imported.

[SCasarotto]

I am also experiencing this issue. I have tired adjusting the node version, updating packages, and CI=true GENERATE_SOURCEMAP=false with no luck.

[StevenFlecha]

same problem here .. fixing babel didn't work

[luminaxster]

TL;DR: Add this option to the script command --max_old_space_size=4096.
Plenty of comments have buried a temporary fix shared by @buncismamen :

I also got the error with new project npx create-react-app and installing plotly

adding the memory flag to start scripts fixing the issue

"start": "react-scripts --max_old_space_size=4096 start",

Please, make sure you don't allocate more RAM than your machine has.

[BudickDa]

TL;DR: Add this option to the script command --max_old_space_size=4096.
Plenty of comments have buried a temporary fix shared by @buncismamen :

I also got the error with new project npx create-react-app and installing plotly
adding the memory flag to start scripts fixing the issue

"start": "react-scripts --max_old_space_size=4096 start",

Please, make sure you don't allocate more RAM than your machine has.

Throwing memory on a memory problem is not a fix.

If max_old_space_size is "fixing" your problem, something is not getting garbage collected which means your code or some package your using is doing some weird stuff.
In any case: You need to find and fix the problem!

[luminaxster]

@BudickDa what part of temporary fix didn't you get? Trying to play clever by stating the obvious? I do NOT maintain this codebase, and until they find the software defect that causes this application failure, I have used that configuration setup to avoid it but the thread has become pretty long.
Take your hot-takes and ranting somewhere else.

[BudickDa]

@luminaxster: You tl;dr is at least honest, because you did not read through the comments and linked issues.
You fix is not a fix, not even a quick fix. It just delays the problem until you run out of memory again.

There are a lot of different solutions in this thread, because this error can have many different reasons.

If people have this problem, they should first look at their code maybe they do something stupid (like I did).
Or they have circular references (https://github.com/facebook/create-react-app/issues/8413)
Maybe node.js is being node.js and they need to remove and reinstall the modules.
Bump the version of babel (https://github.com/facebook/create-react-app/issues/8096#issuecomment-567584040).
Or their are using weird packages and need to fix/disable the generation of sourcemap (https://github.com/babel/babel/pull/10890).

If this doesn't help:
Create a new project, add your packages and import them.
If the error occurs, maybe there is a problem with one of the dependencies.
If there is no error:
Start adding code until it stops working. Try to import max. one new dependency per iteration.
If adding your code piece by piece is too much work, maybe rethink the overall architecture.

[mikeokner]

I had this issue running builds (only in Docker with fresh install of node_modules, not on macOS) after upgrading from Node v10 to v14 and running npm upgrade with "react-scripts": "^3.4.1" and "@babel/core": "^7.10.4".

Setting --max_old_space_size felt hacky to me so I avoided that option.

Adding GENERATE_SOURCEMAP=false to my .env file in the repo fixed the issue.

[brianqian]

I'm running into this issue with react-pdf 2.0.0 on react-scripts: 3.4.1. I've tried updating @babel/core to the latest, (7.10.4), adding it to resolutions with no luck. GENERATE_SOURCEMAP=false works but I need the sourcemaps for dev tools. While the --max_old_space_size solution works, the build time and resource utilization becomes insane. Is downgrading to react-scripts 3.2 the fix here?

Edit: Downgrading to 3.2 works for me

[Hexavolus]

I had a similar issue that was solved by upgrading from node10 to node12. Give that a shot if you're not already on LTS.

[mgandley]

Also running into this. Disabling source maps worked, but not an ideal solution.

[maximelebastard]

I've got the issue too with a fairly simple project. And I don't have control over my CI node version unfortunately. Hopefully, disabling source maps stills allows us to deploy.

[timminkov]

We're having a similar issue running tests on CI.

We hit:

ENOMEM: not enough memory, read

      at ScriptTransformer._transformAndBuildScript (node_modules/@jest/transform/build/ScriptTransformer.js:509:43)
      at ScriptTransformer.transform (node_modules/@jest/transform/build/ScriptTransformer.js:579:25)
      at Object.<anonymous> (node_modules/airbnb-prop-types/src/index.js:26:1)

Edit:
--max_old_space_size=4096 seems to temporarily fix the issue.

[makemefeelgr8]

I am getting this error every time I try to build. The following lines:
react-scripts --max_old_space_size=4096 start
or
react-scripts --max-old-space-size=4096 start
do nothing at all. Every crash report contains:
"--max-old-space-size=2048",
line. So, on top of not working properly, create react app ignores command line arguments.

[christophehurpeau]

@makemefeelgr8 node --max-old-space-size=4096 ./node_modules/.bin/react-scripts start ?

[makemefeelgr8]

@makemefeelgr8 node --max-old-space-size=4096 ./node_modules/.bin/react-scripts start ?

There is no way this will work as I'm using Windows. Anyway, it turned out to be a typescript issue. I had to increase memoryLimit to make it work:
https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/blob/master/README.md#options

[alexfromapex]

Can confirm what @chawax was saying in our heap snapshot we see lots of retained size coming from source maps.

The problem in our codebase was traced to import * from './module'; statements. Make sure you avoid those in your test code and use import { whatYouNeed } from './module'; syntax instead to avoid adding lots of extra stuff in RAM that hangs around.

[klausbreyer]

For me, removing
import * as serviceWorker from "./serviceWorker";

fixed it. Guessing the import * was it.

[ievgennaida]

"Creating an optimized production build... "
is taking forever and than failing.

Setting --max_old_space_size=4096 helps locally,

but it's fails to build prod with docker!
I have tried to set 8192 but I have the same problem!

--max_old_space_size=8192

List of the packages:

{ "dependencies": {
    "@material-ui/core": "4.11.0",
    "@material-ui/icons": "4.9.1",
    "@material-ui/lab": "^4.0.0-alpha.56",
    "@testing-library/jest-dom": "5.11.4",
    "@testing-library/react": "10.4.9",
    "@testing-library/user-event": "12.1.3",
    "@types/jest": "26.0.9",
    "@types/node": "14.0.27",
    "@types/react": "16.9.46",
    "@types/react-dom": "16.9.8",
    "@types/react-plotly.js": "2.2.4",
    "@types/react-router-dom": "5.1.5",
    "fontsource-roboto": "3.0.3",
    "node-sass": "4.14.1",
    "plotly.js": "1.54.7",
    "react": "16.13.1",
    "react-dom": "16.13.1",
    "react-plotly.js": "2.4.0",
    "react-router-dom": "5.2.0",
    "react-scripts": "^3.4.3",
    "react-virtual": "^2.2.4",
    "rxjs": "6.6.2"
  },
  "scripts": {
    "start": "react-scripts --max_old_space_size=4096 start",
    "build": "react-scripts --max_old_space_size=4096 build",
  },
  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "3.9.0",
    "@typescript-eslint/parser": "3.9.0",
    "@types/webpack-env": "^1.15.2",
    "typescript": "^3.9.7"
  }

[tavareshenrique]

@ievgennaida try to change your build command to this:

"build": "CI=true GENERATE_SOURCEMAP=false react-scripts build"

disabling source maps for production build works for me.

[razbensimon]

Is there a way to pass that WITHOUT disabling sourcemaps in production ?!

[razbensimon]

Is there a way to pass that WITHOUT disabling sourcemaps in production ?!

A simple workaround, which works for me also in CI/Jenkins environment
NODE_OPTIONS='--max-old-space-size=8192' npm run build

[strizzaflex]

@robsco-git your post (https://github.com/wojtekmaj/react-pdf/issues/498#issuecomment-566948710) took me down the right path. Indeed my issue was pdfjs. I'm not sure exactly why this is still and issue as the version of react-scripts Im using 3.4.0 has the fixed version of babel (https://github.com/babel/babel/issues/10875).

To solved this I removed direct imports of pdfjs from my code and instead moved to using a cdn to deliver pdfjs. Anyhow, for me the issue was with babel and pdfjs.

[ItsNoHax]

Has anyone tried with V4? I noticed NODE_OPTS got deprecated/removed.

[tmarshall07]

or me, removing
import * as serviceWorker from "./serviceWorker";

fixed it. Guessing the import * was it.

Likewise this worked for me. I had this in my src/index.js file:

// ...
import * from './serviceWorker';
// ...
serviceWorker.unregister();

and I changed it to:

// ...
import { unregister } from './serviceWorker';
// ...
unregister();

and that seemed to do the trick, built in 58s (after taking significantly longer and ultimately failing).

[aximusnl]

Has anyone tried with V4? I noticed NODE_OPTS got deprecated/removed.

V4 introduced this problem for me. Also compiling takes considerably longer.

[waynebrantley]

V4 fixed this problem for me.

[aximusnl]

V4 fixed this problem for me.

Disabling FAST_REFRESH (#8582) fixed it for me in V4 (never had the issue in V3).
Side effect: no refresh at all

[baxxos]

I am still getting this on 4.0 and it's been almost a year now - any updates/solutions?