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 #8130 (comment)

[abrcdf1023]

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

[MichaelCharles]

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 wojtekmaj/react-pdf#498 (comment) - 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.

[cgratie]

My personal experience with this bug: GENERATE_SOURCEMAP=false works in some cases, but not always:

• enough RAM available => no bug
• limited RAM (2GB - t2-small instance on AWS) => bug
  • BUT with additional --max_old_space_size=2048 => no bug (slow)
  • AND after successful build (for example as above) I can remove --max_old_space_size and the build will succeed (and run faster too). If, however, I then remove the cache from node_modules/.cache, the build fails again as before.

Maybe this can help debug the issue.

[pavankjadda]

I have new react project and I still see this error even after setting max old space size

react-scripts --max_old_space_size=4096 build

I am using react-scripts version 4.0.3 and react version 17.0.2

[Dineshchitta]

In my case, I tried increasing heap memory space to 4 GB but the build is getting very slow(Other solutions like Upgrading babel,CRA,Node didn't work for me). When the build is success with 4GB Heapspace I observed that nearly 8 - 10 chunk files sizes are nearly 1MB. So I analyzed all those chunks using Source map explorer. In all chunks almost same libraries code is included (In my case those are Firebase, Video player, etc which are heavy)

So In my assumption when webpack is trying to bundle all these chunks It had to build all those libraries dependency graph in every chunk which in turn causes heap memory space issue. So I used Loadable components to lazy load those libraries.

After lazy loading all those libraries all chunks files size is reduced almost by half, And Build is getting success without increasing any heap space and build time also got reduced.

After optimization if I keep build in 6vCPU , i7 System it is taking around 3 - 4 minutes and I observed that based on the number of Cores available in the system build time is getting reduced. If I keep build in 2vCPU system it is taking around 20 - 25 mins like that sometimes

[sharma-sudhakar]

I have new react project and I still see this error even after setting max old space size

react-scripts --max_old_space_size=4096 build

I am using react-scripts version 4.0.3 and react version 17.0.2

I am getting the same error. Did anyone find any workaround?

[ghost]

I have new react project and I still see this error even after setting max old space size

react-scripts --max_old_space_size=4096 build

I am using react-scripts version 4.0.3 and react version 17.0.2

I am getting the same error. Did anyone find any workaround?

No, but in my case one specific dependency causing the issue. Once I remove it, the issues went away. I know it does not solve the original issue, but a temporary solution

[tlester]

Yeah.. I have min max_old_space_size set to 16384 and it's STILL failing after 40 minutes. It's ridiculous. Builds in 45 seconds on my workstation. Build on google cloud run, and it's 40 minutes. What gives?

[SamKirkland]

@tlester see my comment above. max_old_space_size does NOT set the typescript memory size without modifications via craco

[LucasHang]

Any update about that? I've already tried increasing max_old_space_size but it didn't worked.
I'm searching for anything that may cause this, but founded nothing till now :(

[martenrichter]

This happens again with [email protected]. For me it is caused by:
import pdfjsWorker from 'pdfjs-dist/legacy/build/pdf.worker.entry'
and can be fixed by deactivating building sourcemaps. It did not occur however on 4.0.3 .

[Fullchee]

What worked for me

• cloning the repo in a different folder.

What didn't work for me

• deleting folder and re-cloning it in the same folder but I got the JavaScript Heap out of memory error.
• adding the --max-old-space-size flag
• restarting the VM

What may have caused this for me

• npm linking with another local package

Environment

I've only had this problem on my AWS Workspace (Windows 10) and not my Mac.

[zachkirsch]

+1 I have been getting out of memory errors when running craco start since upgrading to [email protected]

[andr30z]

In my case, I tried increasing heap memory space to 4 GB but the build is getting very slow(Other solutions like Upgrading babel,CRA,Node didn't work for me). When the build is success with 4GB Heapspace I observed that nearly 8 - 10 chunk files sizes are nearly 1MB. So I analyzed all those chunks using Source map explorer. In all chunks almost same libraries code is included (In my case those are Firebase, Video player, etc which are heavy)

So In my assumption when webpack is trying to bundle all these chunks It had to build all those libraries dependency graph in every chunk which in turn causes heap memory space issue. So I used Loadable components to lazy load those libraries.

After lazy loading all those libraries all chunks files size is reduced almost by half, And Build is getting success without increasing any heap space and build time also got reduced.

After optimization if I keep build in 6vCPU , i7 System it is taking around 3 - 4 minutes and I observed that based on the number of Cores available in the system build time is getting reduced. If I keep build in 2vCPU system it is taking around 20 - 25 mins like that sometimes

Thanks, using LoadableComponents resolved the problem for me.

[AmrAbdulrahman]

For TypeScript folks out there:

The Problem:
I have been facing the same problem for few days now. --max-old-space-size won't help. since it doesn't forward the heapLimit to ForkTsCheckerWebpackPlugin

https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/blob/main/README.md#options
Default spaceLimit is 2048.

CRA doesn't send any value for spaceLimit here: https://github.com/facebook/create-react-app/blob/main/packages/react-scripts/config/webpack.config.js#L720

My solution:
I already use react-app-rewired along with customize-cra to provide configs for CRA.
What I did is to simply find and replace ForkTsCheckerWebpackPlugin plugin as following:

config-overrides.js

const { override, useBabelRc, removeModuleScopePlugin, addWebpackPlugin } = require('customize-cra');
const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');
const paths = require("react-scripts/config/paths.js");
const resolve = require('resolve');

module.exports = (config, webpackEnv) => {
  // https://github.com/facebook/create-react-app/blob/main/packages/react-scripts/config/webpack.config.js#L101
  const isEnvDevelopment = webpackEnv === 'development';
  const isEnvProduction = webpackEnv === 'production';
  const shouldUseSourceMap = process.env.GENERATE_SOURCEMAP !== 'false';

  // feel free to find a smarter way to detect and grab the plugin index 🤷‍♂️ 
  const forkTsCheckerWebpackPluginIndex = config.plugins.findIndex(plugin => {
    const  options = plugin.options || {}
    return "async" in options && "typescript" in options && "issue" in options && "logger" in options;
  });


  // copied from: https://github.com/facebook/create-react-app/blob/main/packages/react-scripts/config/webpack.config.js#L720
  // and only increased the memory limit
  const heapSizeLimit = 9000;
  const newTsCheckerWebpackPlugin = new ForkTsCheckerWebpackPlugin({
    async: isEnvDevelopment,
    typescript: {
      memoryLimit: heapSizeLimit,
      typescriptPath: resolve.sync('typescript', {
        basedir: paths.appNodeModules,
      }),
      configOverwrite: {
        compilerOptions: {
          sourceMap: isEnvProduction
            ? shouldUseSourceMap
            : isEnvDevelopment,
          skipLibCheck: true,
          inlineSourceMap: false,
          declarationMap: false,
          noEmit: true,
          incremental: true,
          tsBuildInfoFile: paths.appTsBuildInfoFile,
        },
      },
      context: paths.appPath,
      diagnosticOptions: {
        syntactic: true,
      },
      mode: 'write-references',
      // profile: true,
    },
    issue: {
      // This one is specifically to match during CI tests,
      // as micromatch doesn't match
      // '../cra-template-typescript/template/src/App.tsx'
      // otherwise.
      include: [
        { file: '../**/src/**/*.{ts,tsx}' },
        { file: '**/src/**/*.{ts,tsx}' },
      ],
      exclude: [
        { file: '**/src/**/__tests__/**' },
        { file: '**/src/**/?(*.){spec|test}.*' },
        { file: '**/src/setupProxy.*' },
        { file: '**/src/setupTests.*' },
      ],
    },
    logger: {
      infrastructure: 'silent',
    },
  });

  // replace old with new ForkTsCheckerWebpackPlugin
  config.plugins.splice(forkTsCheckerWebpackPluginIndex, 1, newTsCheckerWebpackPlugin);

  return override(
     // i have project specific configs here using `customize-cra` (useBabelRC() for example)
  )(config);
}

I also disabled source map generations unfortunately.
.env

GENERATE_SOURCEMAP=false

Hope that will help you people!

[matiasfacio]

I have new react project and I still see this error even after setting max old space size

react-scripts --max_old_space_size=4096 build

I am using react-scripts version 4.0.3 and react version 17.0.2

This did it for me. thanks! Do you know why this might work like in my case did?

[egorgrushin]

My solution based on @AmrAbdulrahman solution:

module.exports = function override(config) {
    const forkTsCheckerWebpackPlugin = config.plugins.find(
        (plugin) => plugin.constructor.name === 'ForkTsCheckerWebpackPlugin',
    );
    if (forkTsCheckerWebpackPlugin) {
        forkTsCheckerWebpackPlugin.options.typescript.memoryLimit = 8192;
    }

    return config;
};

[DamianDobrev]

My solution based on @AmrAbdulrahman solution:

module.exports = function override(config) {
    const forkTsCheckerWebpackPlugin = config.plugins.find(
        (plugin) => plugin.constructor.name === 'ForkTsCheckerWebpackPlugin',
    );
    if (forkTsCheckerWebpackPlugin) {
        forkTsCheckerWebpackPlugin.options.typescript.memoryLimit = 8192;
    }

    return config;
};

That fixes the issue for me as well and it's the most non-intrusive answer so far because it does not overwrite any of the previously set TS configuration.