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

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

It’s because of the new threads implementation from eslint-webpack-plugin: https://github.com/webpack-contrib/eslint-webpack-plugin/issues/52#issuecomment-735684551

Reverting back to 2.3.0 should temporarily fix the issue. That can easily be done by adding at the end of package.json:

  "resolutions": {
    "react-scripts/eslint-webpack-plugin": "2.3.0"
  }

and yarn again. Re-compile time should be back to normal

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.

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.

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?

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

This might be an unpopular opinion but y’all are beating a dead horse here I’d say. It seems that the time is up for Create React App now that there’s a way to migrate to and incrementally adopt Next.js which is far superior in my opinion. If I remember correctly, React core team supports Next.js initiative so there’s probably not much motivation to keep supporting both projects proactively since there’s a certain amount of functional overlap.

PS: I am in no way affiliated with Next or Vercel. This is just my personal take so please take it with a grain of salt.

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

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

I just found out that on .env we can add DISABLE_ESLINT_PLUGIN=true

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

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.

Can confirm that installing eslint-webpack-plugin v2.4.1 improves the issue. Thanks @eek!

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?

I cut down my HMR update time a lot by using craco to have a custom start script which disables ESLint without disabling it anywhere else (editor, husky git hooks, or any other tooling).

Install: npm i craco -S

craco.config.js:

module.exports = {
  eslint: {
    enable: false
  }
}

package.json:

  "scripts": {
    "start": "craco start",
    "start:eslint": "react-scripts start",
    "build": "react-scripts build",
    "lint": "eslint . --max-warnings 0"
  }

I will check out Next.js though. Maybe it’s worth switching, i’ve used Next.js before, and only went with CRA because i didn’t need any backend for my current project.

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.

I’m using windows and yarn start is taking more than 15 minutes to run craco start

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.

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

now eslint-webpack-plugin 2.4.1 is available which solves the problem!

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

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

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.

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

For those still struggling with recompile speeds, one of the reasons it may be slower in v4 is because the lint will run on every compile using the config in your own custom .eslintrc if one exists. For most typescript users this will usually involve some typescript rules which can be super slow to run on every build.

Try running eslint across your whole codebase manually (with a cache) and see how much that takes, if this is the problem it should take about as long as your compiles take.

There’s a discussion here about being able to disable eslint runs on compile altogether, which makes sense if you have a custom .eslintrc and already have eslint running in your editor and CI.

In the meantime, I have personally disabled the eslint build using patch-package with this patch:

diff --git a/node_modules/react-scripts/config/webpack.config.js b/node_modules/react-scripts/config/webpack.config.js
index eddca1b..3a895d1 100644
--- a/node_modules/react-scripts/config/webpack.config.js
+++ b/node_modules/react-scripts/config/webpack.config.js
@@ -750,7 +750,7 @@ module.exports = function (webpackEnv) {
           // The formatter is invoked directly in WebpackDevServerUtils during development
           formatter: isEnvProduction ? typescriptFormatter : undefined,
         }),
-      new ESLintPlugin({
+        isEnvProduction && new ESLintPlugin({
         // Plugin options
         extensions: ['js', 'mjs', 'jsx', 'ts', 'tsx'],
         formatter: require.resolve('react-dev-utils/eslintFormatter'),

That’s not an ideal long term solution but better than the cumulative hours you’ll spend waiting for eslint to run on every compile.

I filed a PR, let’s see whether they are willing to fix it for all pre-existing users: https://github.com/facebook/create-react-app/pull/10265

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

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.

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.

@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',
  ],

I have updated to new “eslint-webpack-plugin”: “version”: “2.4.1”, but still facing slow compilation

Yes updating to ^2.4.1 internally in react-scripts would solve the problem, and maybe this is a solution, but would need to be part of another release of react-scripts (maybe 4.0.2 when there are other things ready to release). I’m sure they’d welcome a one-liner PR referencing this issue.

For reference, react-scripts does not lock down to precise versions, it is up to your own package-lock to do this, which is pretty standard behaviour across the npm/js community.

I fully agree that the npm community should not lock down each and every precise version, but this was a critical bugfix that rendered react-scripts almost unusable.

If there are performance regressions that are as crippling as this issue, then I think that the maintainers have to bump the minimum version if they are serious about fixing the bug for all existing users (instead of forcing people to read GitHub issues or deleting their package-lock file).

So yes, maybe I should try to get a small PR merged.

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

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.

This is also in line with my observations. For example, my PR https://github.com/facebook/create-react-app/pull/10265 did not even receive a single comment from the maintainers. Also the number of ignored issues and PRs seems to be devastating. It seems that Facebook has lost interest in cra, and now the project is sailing in “minimal maintenance mode”.

Update: Installing "eslint-webpack-plugin": "^2.4.1" saved the development-speed of our projects, so we are able to use create-react-app again without being forced to downgrade to 3.X.

Thanks to @eek for saving us from downgrading 👍

It would be nice to add this workaround to official docs, otherwise the dev-experience could become extremely painful for newcomers.

See https://github.com/facebook/create-react-app/issues/10154#issuecomment-734423900 as possible workaround.

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.

@aprilmintacpineda That’s a nice move. Really reduced the compile time

“resolutions”: { “react-scripts/eslint-webpack-plugin”: “2.3.0” }

after doing this the compiler 4*faster than b4

Same slowness here as well, going back to 3.4 as ti works much faster.

Unfortunately upgrading to react-scripts 4.0.1 did not fix the slow devServer ( #9909 (comment) ). And hot reloading still takes 6x more time for me than react-scripts 3 with @pmmmwh/react-refresh-webpack-plugin.

Exactly the same here! Switching back to 3.4 🤷‍♂️

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.

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 I do agree with you though in using nextjs when it is possible as a solution, about 80% of my projects run on nextjs and vercel, but yea still has that 20% percent that is dependant on cra. It would be created to see the same interactivity from the cra team as nextjs. Both teams have been innovative but yea nextjs takes the cake if you count the progress they made and the excellent dev experience they provide 🖥️

and same this is just my personal opinion. 😉

Thanks for the suggestions. I am not going to switch immediately, but I fully understand the need for alternatives like Next.js. In fact, this issue has been a huge disappointment and I really lost confidence in cra.

@castynet React^17 is the one thing you don’t have to give up though, because react-scripts v3 already supported it even before v4.

If you got here & none of the solutions above have sorted your Issue, just fall back to the last best version that worked for you, I was using react ^17 and react scripts ^4.0 but I went back to "react": "16.13.1", and "react-scripts": "3.4.4", Its terrible advice, but I don’t care an awful lot about the improvements in 17, at least not as much as I care about my productivity and development speeds, and with the new stuff that is being disrupted. Its a very ‘noob’ approach but along the line someone will fix it, then I can enjoy 17.

edit; as @amcsi mentioned below you can keep react v17

I update node to node 15 and also used node 14 LTS version… and it was compiling slow. Use the previous version of node. i used node v13.10.1 and it fixed the issue! Also don’t bother with nvm. When you put nvm in bash_profile it slows down start up when you open terminal. just go here https://nodejs.org/en/download/releases/ it downloads node and npm so they are both compatible with each other.

Changelog for 2.4.1: https://github.com/webpack-contrib/eslint-webpack-plugin/releases/tag/v2.4.1

I can confirm. Doing what @eek said seemed to bring my fast refresh time back to <1s like with react-script 3.4.0. I would like to wait and see what others say too.

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.

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.

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

Greetings, i was using “react-scripts”: “5.0.1”. For development server it is taking high ram consumption of 3-4GB. After a single change system RAM is increasing to 5 GB and the server is stopping on complete RAM consumption, saying JavaScript heap out of memory. Also the recompiling time is varying between 8-15 seconds. why is it happening like this?

@PaulPCIO fair enough. I acknowledge my response does not cover all of the possible use cases and it wasn’t my goal anyway. I was responding to the majority who use CRA on the web. There may be more alternatives for some of us than others. My point still stands, though. From my perspective, this project could greatly benefit from onboarding more proactive maintainers who can review and merge pull requests from its large open-source community and overall manage this project. I believe that’s what’s causing all delays and ostensible lack of interest or motivation. I don’t want to offend any active members so please don’t hate me for saying this out loud. This is just my current perspective.

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