Since updating to 3.3.0, running out of memory

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)

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.

I also encountered the same problem in the company project.

me too

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.

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

Yes to both.

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

I am on v12.11.0

I am on v13.2.0

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?

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?

@tlester

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

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 :(

This happens again with react-scripts@5.0.0. 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 .

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.

+1 I have been getting out of memory errors when running craco start since upgrading to react-scripts@5.0.0

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.

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!

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?

@AmrAbdulrahman

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;
};

@AmrAbdulrahman

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.

Navigation Menu

Repository navigation

Since updating to 3.3.0, running out of memory #8096

Describe the bug

Did you try recovering your dependencies?

Environment

125 remaining items

What worked for me

What didn't work for me

What may have caused this for me

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Since updating to 3.3.0, running out of memory #8096

Description

Describe the bug

Did you try recovering your dependencies?

Environment

Activity

endiliey commented on Dec 6, 2019

xiaoxiangmoe commented on Dec 6, 2019

anhquande commented on Dec 6, 2019

daviseford commented on Dec 6, 2019

mrmckeb commented on Dec 6, 2019

daviseford commented on Dec 6, 2019

MasterCassim commented on Dec 8, 2019

daviseford commented on Dec 8, 2019

xiaoxiangmoe commented on Dec 9, 2019

125 remaining items

sharma-sudhakar commented on Jul 11, 2021

tlester commented on Aug 8, 2021

SamKirkland commented on Aug 10, 2021

LucasHang commented on Dec 21, 2021

martenrichter commented on Jan 8, 2022

Fullchee commented on Jan 28, 2022

What worked for me

What didn't work for me

What may have caused this for me

Environment

zachkirsch commented on Jan 31, 2022

andr30z commented on Feb 1, 2022

AmrAbdulrahman commented on Jun 21, 2022

matiasfacio commented on May 4, 2023

egorgrushin commented on Jun 13, 2023

DamianDobrev commented on Jun 20, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions