create-react-app: [Bug] CircleCI + Terser Error: Call retries were exceeded

Activity

I think that this issue still exists.

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

I was able to get around the Error: Call retries were exceeded error by increasing the instance type for the job in the circleci yaml config by adding resource_class: large. I think the error occurs when the build requires more memory than what the circleci instance allows.

.circleci/config.yml

  build:
    resource_class: large # <--- ADD THIS
    working_directory: ~/project

The craco workaround posted in the above comments did not work for me.

@stalebot take a holiday mate

I don’t think that this issue should be closed. We’re still having to use craco to have insight into the Terser config and parallel setting

const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
  webpack: {
    configure: (webpackConfig) => ({
      ...webpackConfig,
      optimization: {
        ...webpackConfig.optimization,
        minimizer: [
          new TerserPlugin({
            terserOptions: {
              parse: {
                ecma: 8,
              },
              compress: {
                ecma: 5,
                warnings: false,
                comparisons: false,
                inline: 2,
                drop_console: true,
              },
              mangle: {
                safari10: true,
              },
              output: {
                ecma: 5,
                comments: false,
                ascii_only: true,
              },
            },
            parallel: 2,
            cache: true,
            sourceMap: false,
            extractComments: false,
          }),
        ],
      },
    }),
  },
};

@kyeotic this was a hacky approach that worked for us

I see here https://github.com/facebook/create-react-app/pull/6732/files that similar problem was fixed specifically for single use case. Why not fixing this for everybody ? Seems lot of build pipelines are very unstable because of Terser. We also have issues with running build on Circle CI.

@christophehurpeau advised adding option to configure this. I believe this would solve a lot of problems with builds instabbility.

I was having the same issue on AWS Amplify, and wanted to find a solution other than updating the Webpack configuration. Resolving the terser-webpack-plugin to the latest version did the trick for me without any build errors (even though I jumped two major versions with this change):

{
  "resolutions": {
    "terser-webpack-plugin": "4.1.0"
  }
}

Having the same issue on circle ci

Please do not close. It’s still an open issue.

I am using similar workaround as above, just by using react-app-rewired and having this loop to alter config:

config.optimization.minimizer.forEach(minimizer => {
  if (minimizer && minimizer.options && minimizer.options.parallel === true) {
    minimizer.options.parallel = 1;
  }
});

Would be good to have this CPU detection fixed properly, alternatively having option to turn OFF parallelization.

Forcing terser-webpack-plugin to a more recent version seems to have solved this issue for me. Thanks @sammarks.

package.json
{
  "resolutions": {
    "terser-webpack-plugin": "4.2.3"
  }
}

If I’m not mistaken this is mainly due to this fix, so any version newer than 2.3.3 would do. (react-scripts@4.0.3 uses webpack@4.44.2 which has a dependency on terser-webpack-plugin@1.4.3.)

So to solve this issue, all that has to be changed is to update dependencies. I guess it’s tracked in #9994.

Just a note - the Craco solution works well for this issue, but be aware that the config above turns off sourceMap - which you may want to enable for your production build.

A quick fix would be having an environment variable for setting the parallel configuration option.

Issue opened since January! This needs to be fixed

We encountered the same issue on our own GitLab instance, increasing CPU and memory limits of the CI containers solved it. This solution only works if you host the CI by yourself, though.

package.json { “resolutions”: { “terser-webpack-plugin”: “4.2.3” } }

This finally worked for me! This is simpler than using craco or the equivalent. Thank you for saving me from going insane … Thanks to @graup and @sammarks

if anyone find this issue by google, please check the memory usage during npm run build

@hernanif1 my best guess is that suspense (ie code splitting) is the root cause of this. we started seeing failures on CI after code splitting, and on revert, with everything else staying the same, the issue did not show up. the nice part of the workaround is that we are able to continue to use code splitting

Yeah, this is still and issue for me as it’s hapenning also with Bitbucket Pipelines and CRA.

Quick update, the workaround for now is setting explicitly parallel option.

https://github.com/webpack-contrib/terser-webpack-plugin#parallel

Explanation: https://github.com/webpack-contrib/terser-webpack-plugin/issues/202#issuecomment-580704210

@hernanif1 Maybe you could try and configure terser in a such way: https://auth0.com/blog/how-to-configure-create-react-app/ (from https://create-react-app.dev/docs/alternatives-to-ejecting)

@ebwittenberg

According to docs, that disables parallel running (it is the same as False):

https://github.com/webpack-contrib/terser-webpack-plugin#parallel

By default the parallel is calculated based on number of available cpus, but since CircleCi doesn’t provide a reliable value for this, this usually explodes memory usage (because the number of instances/parallel is too high).

One workaround is to setting this value by hand (and not relying on CircleCi fake cpu count), but for this you need better machines (not the free ones).

The other option is disabling parallel. (In my case, I didn’t need to have a more expensive machine). It may be a little bit slower but it was cheaper .

For those arriving late here:

I’ve build a solution based on #8320 (comment)

The first solution was removing OptimizeCSSAssetsPlugin from optimization.minimizer list.

Also, my solution keeps the same original settings that create-react-app provides (and is more future proof).

After installing craco add the following config

// craco.config.js
const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
  webpack: {
    configure: (webpackConfig) => ({
      ...webpackConfig,
      optimization: {
        ...webpackConfig.optimization,
        // Workaround for CircleCI bug caused by the number of CPUs shown
        // https://github.com/facebook/create-react-app/issues/8320
        minimizer: webpackConfig.optimization.minimizer.map(item => {
          if (item instanceof TerserPlugin) {
            item.options.parallel = 0;
          }

          return item;
        })
      },
    }),
  },
};

If your CircleCI build is too slow or you still getting out of memory errors you can also disable source maps (memory heavy) in .env file:

# .env
GENERATE_SOURCEMAP=false

@onilton this worked for me, but what is it doing when item.options.parallel is set to 0? It seems that other solutions involve increasing the number of parallel processes.

“me too” comments are noise. A hack-solution was posted above, but the problem remains. Asking if it has been solved to keep the issue active is one thing, but that was done 9 days ago. The addition of a stack trace and your config is just more confirmation that you are experiencing the issue. Its not helpful though, nobody is arguing that the issue exists so there is nobody to convince. Your post isn’t adding any value, only people subscribed to this thread will see it and its already active. “me too” is just noise.

If you want to raise the attention of the issue upvote/emoji-react the first comment so that it sorts higher on the issue page.

Does anyone have solutions to this issue yet?

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10096d6b6 node::Abort() (.cold.1) [/usr/local/Cellar/node@10/10.17.0/bin/node]
 2: 0x10003b8d0 node_module_register [/usr/local/Cellar/node@10/10.17.0/bin/node]
 3: 0x10003ba91 node::OnFatalError(char const*, char const*) [/usr/local/Cellar/node@10/10.17.0/bin/node]
 4: 0x100178d87 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/Cellar/node@10/10.17.0/bin/node]
 5: 0x100178d29 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/Cellar/node@10/10.17.0/bin/node]
 6: 0x10042d29c v8::internal::Heap::UpdateSurvivalStatistics(int) [/usr/local/Cellar/node@10/10.17.0/bin/node]

<--- Last few GCs --->
io[7451:0x103b0d000]    22914 ms: Mark-sweep 1399.1 (1416.2) -> 1398.9 (1417.2) MB, 719.4 / 0.0 ms  (+ 0.0 ms in 21 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 732 ms) (average mu = 0.137, current mu = 0.017) allocatio[7451:0x103b0d000]    23861 ms: Mark-sweep 1400.5 (1417.2) -> 1400.4 (1418.2) MB, 938.8 / 0.0 ms  (+ 0.0 ms in 25 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 946 ms) (average mu = 0.069, current mu = 0.008) allocatio

<--- JS stacktrace --->

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

    0: ExitFrame [pc: 0x1e4d008dbe3d]
    1: StubFrame [pc: 0x1e4d0088d40b]
    2: ConstructFrame [pc: 0x1e4d0088cfa3]
    3: StubFrame [pc: 0x1e4d00d9d47d]
Security context: 0x323cb0a9e6e9 <JSObject>
    4: _(aka _) [0x323c1b90ef91] [/Users/home/Desktop/repo/node_modules/terser/dist/bundle.min.js:1] [bytecode=0x323cd24c09e1 offset=361](this=0x323c369826f1 <undefined>,n=0x323c36986bd1 <String[4]: name>,i=0x3...

 7: 0x10042eed9 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/usr/local/Cellar/node@10/10.17.0/bin/node]
 8: 0x10042c576 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/Cellar/node@10/10.17.0/bin/node]
 9: 0x10042b387 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/Cellar/node@10/10.17.0/bin/node]
10: 0x1004339ae v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/Cellar/node@10/10.17.0/bin/node]
11: 0x1004339f8 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/Cellar/node@10/10.17.0/bin/node]
12: 0x1004142e7 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/usr/local/Cellar/node@10/10.17.0/bin/node]
13: 0x1005ee60d v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/Cellar/node@10/10.17.0/bin/node]
14: 0x1e4d008dbe3d 

Package config. “terser-webpack-plugin”: “^2.3.5”, “webpack”: “^4.42.0”,

webpack config-

optimization: {
  minimize: true,
  minimizer: [
    new TerserPlugin({
      chunkFilter: chunk => {
        // Exclude uglification for the `vendor` chunk
        if (chunk.name === 'vendor') {
          return false;
        }

        return true;
      },
      cache: true,
    }),
  ],
},

Stopping by to note that I experienced this issue when upgrading react from 16.12.0 to 16.13.0 (an upgrade which included version updates of terser & terser-webpack-plugin in my yarn.lock file).

The craco solution is the way to go for this issue at the moment. Thanks to everyone that contributed above, this was doing my head in.