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

Created on 14 Jan 2020  路  42Comments  路  Source: facebook/create-react-app

Bug

When you use CircleCI to build the project, it will sometimes not compile throwing the error below.

Looks like this is a known problem here: https://github.com/webpack-contrib/terser-webpack-plugin/issues/143#issuecomment-573954013. Recommend setting the webpack configuration based on the feedback.

#!/bin/bash -eo pipefail
yarn build
yarn run v1.21.1
$ react-scripts build
Creating an optimized production build...
Browserslist: caniuse-lite is outdated. Please run next command `yarn upgrade`
Failed to compile.

Failed to minify the bundle. Error: static/js/1.dc6042b5.chunk.js from Terser
Error: Call retries were exceeded
    at /home/circleci/project/node_modules/react-scripts/scripts/build.js:196:23
    at finalCallback (/home/circleci/project/node_modules/webpack/lib/Compiler.js:257:39)
    at /home/circleci/project/node_modules/webpack/lib/Compiler.js:273:13
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/home/circleci/project/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:22:1)
    at AsyncSeriesHook.lazyCompileHook (/home/circleci/project/node_modules/tapable/lib/Hook.js:154:20)
    at onCompiled (/home/circleci/project/node_modules/webpack/lib/Compiler.js:271:21)
    at /home/circleci/project/node_modules/webpack/lib/Compiler.js:681:15
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/home/circleci/project/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)
    at AsyncSeriesHook.lazyCompileHook (/home/circleci/project/node_modules/tapable/lib/Hook.js:154:20)
    at /home/circleci/project/node_modules/webpack/lib/Compiler.js:678:31
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/home/circleci/project/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)
    at AsyncSeriesHook.lazyCompileHook (/home/circleci/project/node_modules/tapable/lib/Hook.js:154:20)
    at /home/circleci/project/node_modules/webpack/lib/Compilation.js:1423:35
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/home/circleci/project/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)
    at AsyncSeriesHook.lazyCompileHook (/home/circleci/project/node_modules/tapable/lib/Hook.js:154:20)
    at /home/circleci/project/node_modules/webpack/lib/Compilation.js:1414:32
Read more here: https://bit.ly/CRA-build-minify

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Exited with code exit status 1
bug report needs triage

Most helpful comment

I think that this issue still exists.

All 42 comments

@amcdnl

It seems that v2.3.3 should fix that (https://github.com/webpack-contrib/terser-webpack-plugin/releases/tag/v2.3.3) but in my project it didn't work...

source: https://github.com/webpack-contrib/terser-webpack-plugin/issues/202#issuecomment-579266611

I had to set explicitly number of cpus for parallel option and now it works.

@hinok @amcdnl do you guys know if there is a workaround without ejecting 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)

@hinok craco https://www.npmjs.com/package/@craco/craco is an easier workaround to ejecting, we are currently using it for this issue

@prithvin excelent suggestion! Do you know if there is something that we could do in our project before implementing your suggestion?
Like reducing the bundle, code spliting?
The main questions is what I'm doing in my create-react-app that triggers this error?

@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

@prithvin Can you share the craco config you used to get this working? Ive tried

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

module.exports = {
  optimization: {
    minimize: true,
    minimizer: [
      new TerserPlugin({
        parallel: 1 // and true, and 2
      })
    ]
  }
}

Which all still fail on circle ci

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

@prithvin Wow that was fast, and it worked! You're a life saver

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

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.

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.

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 think that this issue still exists.

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

Having the same issue on circle ci

Issue opened since January! This needs to be fixed

Yes, facing the same issue and if now I try to downgrade the version of react-script it gives me below error
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined

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

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.

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.

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

still experiencing this issue with "react-scripts": "^3.3.0".
anyone have a solution that is not a hack ?

Could we just add a env variable to define https://github.com/webpack-contrib/terser-webpack-plugin#parallel in the webpack.config.js here ? Something like

      minimizer: [
        // This is only used in production mode
        new TerserPlugin({
          parallel: terserPluginParallelOption,
          terserOptions: {

with

const terserPluginParallelOption = process.env.TERSER_PLUGIN_PARALLEL_OPTION ? parseInt(process.env.TERSER_PLUGIN_PARALLEL_OPTION) : true;

I would be happy to open a PR

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 thevendor` chunk
if (chunk.name === 'vendor') {
return false;
}

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

},
```

@kyeotic any issue with the above configuration?

"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.

@kyeotic got your point. I thought of checking with all the folks who've commented on their workaround/solution.
FYI- I even tired with that hack-solution but no luck.

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.

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.

Activity

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

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

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

That's a great idea. I would be happy to prepare a PR to that end. One of the core ideas of CRA is avoiding configuration and flags - perhaps a maintainer could weigh in if this would violate that principle. This issue does seem to be plauging quite a few people, so perhaps it's worth breaking the rules?

We also had this issue while running react-scripts build inside a docker buildx armv7 container on GitHub actions. Limiting the parallel count and increasing maximum consumed memory that node can use did not solve the issue.

Locally everything went just fine (inside buildx armv7 qemu emulation).

However when running react-scripts build outside the docker buildx builder instance on the GitHub action everything went fine. However it somehow defeats the purpose of having a single dockerfile for building the app.

We added a argument for skipping running react-script build and copying the build assets into the container instead for "resolving" this issue.

The weird thing is that for all other architectures the problem did not arise.

If anyone has the same exact issue here are the workflow file and dockerfile links:

https://github.com/dungeon-revealer/dungeon-revealer/blob/50882946530092e03103e6bc0eeceb8b488f5b4d/.github/workflows/build-docker.yml#L1
https://github.com/dungeon-revealer/dungeon-revealer/blob/50882946530092e03103e6bc0eeceb8b488f5b4d/Dockerfile#L1

For those arriving late here:

I've build a solution based on https://github.com/facebook/create-react-app/issues/8320#issuecomment-586432267

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

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.

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.

Is there any update on this? I have tried most of the solutions but nothing is working...

This also seemed to be a problem in the project I work with.
We use gitlab-ci with docker/k8s on AWS. One of our internal npm-packages updated its deps to this, among others

    "react": "^16.14.0",
    "react-dom": "^16.14.0",
    "react-scripts": "^3.4.4",
    "react-styleguidist": "^11.1.0"

In the application using this package, which is based on react-app-rewired, the pipeline appeared to suddenly have become slower in the build-step and then also failed with the errors:

$ react-app-rewired build
Creating an optimized production  #build...
Failed to compile.
Failed to minify the bundle. Error: static/js/2.4db21d21.chunk.js from Terser
Error: Call retries were exceeded
    at compiler.run (/app/node_modules/react-scripts/scripts/build.js:196:23)

Using the proposed workaround from @jurosh in the _config-overrides.js_ file in the projects root seems to have solved that problem momentarily.

There is a new CRA version 4 that solved my issue.

I updated the following values on the tsconfig.json compiler options and it worked.
"noFallthroughCasesInSwitch": true,
"jsx": "react",

The following solution posted by @miguelmota solved it for me.

.circleci/config.yml

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

It appears that the error message that points at Terser is a red herring - take a look here:

https://github.com/webpack-contrib/terser-webpack-plugin/issues/202#issuecomment-589634287 (TL; DR: terser isn't to blame, a worker proc is running out of memory)

Giving my build more memory solved the problem for me.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

barcher picture barcher  路  3Comments

alleroux picture alleroux  路  3Comments

DaveLindberg picture DaveLindberg  路  3Comments

alleroux picture alleroux  路  3Comments

Aranir picture Aranir  路  3Comments