Create-react-app: Very slow recompile times (~20 seconds)

[FezVrasta]

Describe the bug

(Write your answer here.)

Hi, I'm trying to upgrade from 3.4.1 to 4.0.0 but I noticed that when I make a change it takes approx 20 seconds to recompile. With 3.4.1 it's just a couple of seconds.

Did you try recovering your dependencies?

I deleted node_modules, yarn.lock, and installed the deps.

Which terms did you search for in User Guide?

(Write your answer here if relevant.)

Slow, compile time, recompile.

Environment

Environment Info:

  System:
    OS: macOS 10.15.7
    CPU: (4) x64 Intel(R) Core(TM) i5-4690 CPU @ 3.50GHz
  Binaries:
    Node: 14.5.0 - /usr/local/bin/node
    Yarn: 1.22.5 - /usr/local/bin/yarn
    npm: 6.14.5 - /usr/local/bin/npm
  Browsers:
    Chrome: 86.0.4240.111
    Firefox: 81.0
    Safari: 14.0
  npmPackages:
    react: ^17.0.1 => 17.0.1 (16.14.0)
    react-dom: ^17.0.1 => 17.0.1 (16.14.0)
    react-scripts: ^4.0.0 => 4.0.0 
  npmGlobalPackages:
    create-react-app: Not Found

Steps to reproduce

(Write your steps here:)

1. yarn start
2. change a file
3. observe the time it spends on "Compiling..."

Expected behavior

The recompile time should be almost instantaneous. It also takes a lot of time to start the first time (after yarn start)

Actual behavior

(Write what happened. Please add screenshots!)
The app takes 20 seconds to recompile.

Reproducible demo

(Paste the link to an example project and exact instructions to reproduce the issue.)
Not available, I think it's related to the size of my app (It's 1012 files)

[vlad-khitev-axon]

I have exactly the same problem. In a big TypeScript project (~1000 files) before upgrading to react-scripts@4 any code changes were applied immediately.

Any combination of TSC_COMPILE_ON_ERROR and FAST_REFRESH env variables doesn't affect the compilation time.

 System:
    OS: macOS 10.15.6
    CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
  Binaries:
    Node: 12.18.3 - ~/.nvm/versions/node/v12.18.3/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.6 - ~/.nvm/versions/node/v12.18.3/bin/npm
  Browsers:
    Chrome: 86.0.4240.111
    Edge: Not Found
    Firefox: 80.0.1
    Safari: 13.1.2
  npmPackages:
    react: ^17.0.1 => 17.0.1 (16.14.0)
    react-dom: ^17.0.1 => 17.0.1 (16.14.0)
    react-scripts: ^4.0.0 => 4.0.0 
  npmGlobalPackages:
    create-react-app: Not Found

[balonsom]

I have the same problem, it takes around 20 seconds each time it recompiles. It was not happening on 3.4.1

Environment Info:

  System:
    OS: macOS 10.15.6
    CPU: (8) x64 Intel(R) Core(TM) i7-1060NG7 CPU @ 1.20GHz
  Binaries:
    Node: 14.4.0 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.5 - /usr/local/bin/npm
  Browsers:
    Chrome: 86.0.4240.111
    Edge: Not Found
    Firefox: 81.0
    Safari: 14.0
  npmPackages:
    react: 17.0.1 => 17.0.1 (16.14.0)
    react-dom: 17.0.1 => 17.0.1 
    react-scripts: 4.0.0 => 4.0.0 
  npmGlobalPackages:
    create-react-app: Not Found

[jjhbw]

Same here, recompiles take several times as long as on 3.4.x

[MichaelBurgess]

Same here, I can't viably use 4.0.0 as it stands. Previously I'd get a reload of page in ~2 seconds after changing some code. Now takes ~45 seconds. Initial start time is also about 3-4x slower.

Environment Info:

  System:
    OS: macOS 10.15.7
    CPU: (8) x64 Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz
  Binaries:
    Node: 14.13.0 - /usr/local/bin/node
    Yarn: 1.22.5 - /usr/local/bin/yarn
    npm: 6.14.8 - /usr/local/bin/npm
  Browsers:
    Chrome: 86.0.4240.111
    Edge: Not Found
    Firefox: 81.0
    Safari: 14.0
  npmPackages:
    react: 16.14.0 => 16.14.0
    react-dom: 16.14.0 => 16.14.0
    react-scripts: 4.0.0 => 4.0.0
  npmGlobalPackages:
    create-react-app: Not Found

[ali-master]

Same here, Is there a way to solve this issue?

[FezVrasta]

Is anyone aware of a flag that can be set to make the yarn start command log verbose output? I'd like to understand what's the underlying issue but with the existing log there isn't any information available.

[PaulPCIO]

Having the same issue here 💤

Is anyone aware of a flag that can be set to make the yarn start command log verbose output? I'd like to understand what's the underlying issue but with the existing log there isn't any information available.

@FezVrasta not sure you can do that with a flag, but you can use patch-package to remove this line from react-scripts.
Or you could try one of these methods. I don't think the FORCE_COLOR works anymore.

UPDATE:

I disabled the fast refresh using FAST_REFRESH=false
I then tried injecting it into the webpack config using customise-cra with customize-cra-react-refresh, this is the method I used before cra v4.

The outcome is the same... :-1:

Anyone using a rewired cra that is experiencing this problem?

[ali-master]

Having the same issue here 💤

Is anyone aware of a flag that can be set to make the yarn start command log verbose output? I'd like to understand what's the underlying issue but with the existing log there isn't any information available.

@FezVrasta not sure you can do that with a flag, but you can use patch-package to remove this line from react-scripts.
Or you could try one of these methods. I don't think the FORCE_COLOR works anymore.

UPDATE:

I disabled the fast refresh using FAST_REFRESH=false
I then tried injecting it into the webpack config using customise-cra with customize-cra-react-refresh, this is the method I used before cra v4.

The outcome is the same... 👎

Anyone using a rewired cra that is experiencing this problem?

I have your problem because I've used the react-app-rewired to customize the Create-react-app and I disabled the FAST_REFRESH but I got the same issue and every time I change my code, I have to wait for about 50 seconds to see my changes in the Browser.

[jmcpeak]

I believe the problem may be related to eslint as my IDE which runs eslint on a file save is slow at this task.

[werevamp]

@jmcpeak It was my .eslintrc.js file that was making everything slow for me. This may not work for everyone but it worked for me. I ended up commenting out a few libraries from my extends list and now it is much faster:

  extends: [
    'plugin:@typescript-eslint/recommended',
    // 'airbnb-typescript',
    // 'airbnb/hooks',
    // 'prettier',
    // 'prettier/react',
    // 'prettier/@typescript-eslint',
    // 'plugin:prettier/recommended',
  ],

[RubenMateus]

Same happening with a medium size project. Upgraded to v4 and its takes a bit more time to recompile. around 5-6s,
previous was almost instant.

[houmark]

I've also experienced slow recompile and the only "solution" which is of course not a solution, is to out-comment libraries/plugins.

[FezVrasta]

It may be a coincidence, but running eslint . takes 20 seconds too, so it looks like CRA is running ESlint from scratch on each file change, rather than using a partial approach or some kind of cache.

[vlad-khitev-axon]

Is there a way to completely remove ESLint from the dev compilation process? I believe many developers use ESLint as an IDE extension, so why do we need to duplicate it in react-scripts? I mean, every time developer saves a file, both IDE and react-scripts trigger their own ESLint process.

For me, it would be useful to run the lint command explicitly only in two situations: before a commit (lint-staged) and before a build (react-scripts).

[YannHulot]

I am experiencing the same thing. It takes about 20 seconds to recompile the files and on V4 which obviously is a problem.

[jmcpeak]

Is there a way to completely remove ESLint from the dev compilation process? I believe many developers use ESLint as an IDE extension, so why do we need to duplicate it in react-scripts? I mean, every time developer saves a file, both IDE and react-scripts trigger their own ESLint process.

For me, it would be useful to run the lint command explicitly only in two situations: before a commit (lint-staged) and before a build (react-scripts).

I second this wholeheartedly.

I understand that CRA is meant to get new users up and going quickly along with enforcing good React code practices with eslint which is why it should be turned on by default - for sure.

But it also has another purpose, making a large portion of professional React projects not worry about sane configuration settings, bundling, builds, etc. I hand that work over to the smart folks running this project. I have a bizillion other things to worry about trying to deliver a quality product.

Maybe switching eslint off/on with a flag would be good idea?

[jmcpeak]

I disabled eslint by setting this in package.json:

  "eslintConfig": {
    "ignorePatterns": ["src/*", "!src/test.js"]
  }

_(eslint requires a minimum of one file to work, I gave it test.js)_

And I had to rename my .eslintrc.json file (doesn't speed up unless you do this).
I renamed mine to .eslintrc-ide.json and pointed my IDE's eslint configuration tool to use this file instead.

yarn start feels like its back to _normal_ speed

[vlad-khitev-axon]

In addition to the answer above,
If using VSCode, you can simply add these lines to your .vscode/settings.json:

{
  "eslint.options": {
    "ignorePattern": ["!src/*"],
  }
}

So, in package.json or .eslintrc you ignore the src folder and in the editor settings you revert that.

[wunnle]

Same here, I've disabled react-scripts's eslint in my eslintrc and enabled it again in vscode settings like @vlad-khitev-axon suggested. Now compiling duration is even better than 3.4.1.

However this "solution" is a bit dirty.

[YannHulot]

Following a combination of @jmcpeak and @vlad-khitev-axon' s advice, I managed to fix the compiling issue. Compiling time is back to what it was before the migration to V4.

This is obviously some kind of hack and it does feel dirty to mess with the eslint config as such. Hopefully ther will be a better way to do this in the future.

In the meantime, kudos to the team for pushing v4 out. Besides this small issue the migration was very smooth and nothing else broke.

[akinorimiz]

It does not seem like eslint caching is enabled by default. It would be way faster when I updated options for eslint-webpack-plugin in the node_modules/react-scripts/config/webpack.config.js directly.

new ESLintPlugin({
  cache: true,
  ...

[esetnik]

Will the fix for this be released soon? This is currently blocking us from upgrading to cra v4 as it causes a 10x increase in compilation time on our project.

[jmcrthrs]

@esetnik It has been added to the 4.0.1 milestone: https://github.com/facebook/create-react-app/milestone/78

[houmark]

I hope they don't want to fix all the issues in the 4.0.1 milestone before releasing it, because that seems like it will be some time away — this issue and several others which seems already fixed is blocking the adoption of 4.0 completely for us and I guess many others, so I hope they will release 4.0.1 with everything already merged soon.

[jmcrthrs]

Yes, but perhaps we will just have to wait a little longer and let the development team release using their existing release protocols and not pressure them. There is nothing groundbreaking in 4.0.0.

[PaulPCIO]

You could just use patch-package as a temporary fix and then remove it once the next version has been published.

1. Install patch-package
2. Open the webpack file:
   node_modules/react-scripts/config/webpack.config.js
3. Add cache to the eslint plugin

new​ ​ESLintPlugin​(​{​
  ​cache​: ​true​,​
  ...
})

1. Run the patch package script
   yarn patch-package react-scripts

[houmark]

Fast Refresh is fairly groundbreaking and being able to get on latest ESLint is also pretty nice.

@PaulPCIO not sure how our build system will approve of patch-package but thanks for the hint. I don't see why a bugfix 0.1 should be too hard to do for the CRA team and then move what's not super simple to fix or has no PR to 0.2.

[dwelle]

Even with cache: true it'll still make cold start take ages. I believe we should be able to disable eslint in dev compilation altogether: https://github.com/facebook/create-react-app/issues/9929

[NTag]

Maybe a custom eslint configuration, if present, shouldn't be used by CRA during build?

You may have rules forbidding unused variables or about object key sort, or even forbidding console.log, and it's a pain to write code that follows those rules at any time in the development process. I would expect CRA to execute a basic eslint configuration during dev compiling, but my editor to follow a different more restrictive configuration. I don't want the dev app to fail reloading because I added a console.log or have an unused variable 🤯. But I do want the lint step to fail, or my editor to highlight this issue.

It's also what seems to say the documentation:

Note that even if you customise your ESLint config, these changes will only affect the editor integration. They won’t affect the terminal and in-browser lint output.

But obviously this is wrong with v4, as we can see in this thread.

[FezVrasta]

What I do is to set all my rules to warn and then in CI I run eslint --max-warnings=0 so that the build fails if any rule throws a warning.

[mareksuscak]

For anyone running into this issue and looking for a workaround until CRA 4.0.1 comes out, here's a guide on how you can set it up and be happy from then on.

[MeLlamoPablo]

This is already fixed in master, I think releasing 4.0.1 should be prioritized, and the rest of the issues on the 4.0.1 milestone should be moved to 4.0.2. v4 has been in production for 11 days already, I think there's no excuse for this fix to be unreleased still.

[razor-x]

While we all wait, here are some fun numbers to think about. If this issue affects 1% of the 83k users (GitHub stars) such that they experience a 20s delay on each recompile and on avg make 10 changes per hour per work day, then for every day this fix is not released, 15 days or 370 hours of engineering time is "lost".

This was fixed 10 days ago, so we are up to about 3,700 hours of collective thumb twiddling time 😜

83,000 users * 1% * 8 hours / day * 10 recompile / hour * 20 seconds / recompile
= (83,000 * 1% * 8 hours * 10 / hour * 20 seconds) * (user / day)
~ 370 user-hours per day

[dantman]

This was fixed 10 days ago, so we are up to about 3,700 hours of collective thumb twiddling time 😜

Original: xkcd/303

😅 Sorry, I had to.

[MichaelBurgess]

26 days and still no 4.0.1 release with this in? What's the hold-up? Why stack up tons of fixes into another bigger release which will likely introduce more bugs, instead of doing some smaller, quick-win patch releases to address clear blockers for migrating to v4?

[Snipx]

I second @MichaelBurgess's comment about the release - it would be very valuable for our team to have the new version released sooner than later as this is issue has largest impact on development

[jmcrthrs]

This issue is closed, so the people responsible for releases may not see your comments.

There is currently an open discussion here: https://github.com/facebook/create-react-app/discussions/10097

Perhaps if we add some reactions (and comments) in support, the team may respond there.

[jmcrthrs]

4.0.1 has been released:
https://github.com/facebook/create-react-app/releases/tag/v4.0.1

[amcsi]

Unfortunately upgrading to react-scripts 4.0.1 did not fix the slow devServer ( https://github.com/facebook/create-react-app/discussions/9909#discussioncomment-111667 ). And hot reloading still takes 6x more time for me than react-scripts 3 with @pmmmwh/react-refresh-webpack-plugin.

[alii]

@amcsi on that note, fresh CRA with TS template is able to reproduce (also 4.0.1). Is the current "workaround" to switch back down to 3.4? I haven't had brilliant luck with TypeScript & both 4.0.x versions unfortunately.

[amcsi]

@alii yes, I had to switch back to 3.4.