I always get these compile fails on eslint errors also in CRA 3.x (which is fine).

It depends. For example a simple console.log now also prevents compiling. This was not the case with 3.4.x. There is always the flag TSC_COMPILE_ON_ERROR=true you can set in your .env to compile anyways.

This also breaks on prop warnings, which is very intrusive during development. It would be nice if this could be fixed...

Updated:

Add

emitWarning: true,
failOnWarning: false,

In config/webpack.config.js -> ESLintPlugin

      new ESLintPlugin({
        // Plugin options
        extensions: ['js', 'mjs', 'jsx', 'ts', 'tsx'],
        formatter: require.resolve('react-dev-utils/eslintFormatter'),
        eslintPath: require.resolve('eslint'),
        context: paths.appSrc,
        emitWarning: true, // new
        failOnWarning: false, // new
        // ESLint class options
        cwd: paths.appPath,
        resolvePluginsRelativeTo: __dirname,
        baseConfig: {
          extends: [require.resolve('eslint-config-react-app/base')],
          rules: {
            ...(!hasJsxRuntime && {
              'react/react-in-jsx-scope': 'error',
            }),
          },
        },
      }),

failOnError: false, Don't do that... Skip warnings only

Even more, the compilation time became much longer because it now extends the ESlint config and runs lint on every change, which eliminates the speed of fast refresh. I used ESlint only as a part of lint-staged before and want to continue to use it as an optional thing that won't slow down compilation time.

Try with caching, again add
cache: true,

in ESLintPlugin options.

Caching fixed in this PR: #9911

There is a temporary workaround, but it works for me for now. I renamed .eslintrc to something else which is not findable by cra, like config.eslint.js. Then I changed all eslint scripts in package.json to eslint -c config.eslint.js ...rest of params. The only problem I have now is that my configuration is not working in my editor too, I mean fix eslint errors on save is not working and I should change the configuration file for my editor too. It may not worth it to change all of these also.
In my case I am using coc-eslint and coc-nvim which can be configured to use the new config file as explained here: url.

It feels like webpack.config.js should honour the SKIP_PREFLIGHT_CHECK environment variable something like this abraidwood@39452df

In my case, the errors I got after upgrading were in files that are not included in the build - and thus weren't linted in v3.4.0 but somehow are in v4.0.0. Maybe this is what you're seeing too?

I encountered this issue yesterday 😕 Spend hours trying to understand what was going on. I had to downgrade to v3.4.4, now it's working fine ✨ I wish this issue can be fixed soon

Just want to post some extra context for anyone reading:

Originally CRA used its own config for linting files during build and did not consult main project eslintrc file at all. This was useful because a lot of the rules caught not just style issues but actual runtime bugs (e.g. rules-of-hooks). Also, one could still tell CRA to use project's main lint config via the EXTEND_ESLINT option.

Then in CRA v4.0 that was consolidated (see #9587) - now EXTEND_ESLINT is the default. That removed a lot of ambiguity but now stylistic rule errors block dev build, which is what this thread is all about.

This is actually not such a big issue for initial CRA lint setup (since most rules in eslint-config-react-app are set to "warn") but for those of us using config presets like eslint-config-airbnb, etc, most of the rules are set to "error", and this starts to interrupt workflow. So, when people started upgrading to CRA v4.0, this behaviour began to be very noticeable.

Hopefully the above provides some background information for why this came up at this point in time.

I'd like to be able to disable CRA running of eslint completely. I already have a git precommit hook that runs run eslint & prettier fixing for code layout then will block commit if further rules are failing. I also have linting running on CI as a merge-blocking step (in case anyone disables the precommit hook).

I feel like CRA is dictating and restricting workflow with this change & that is unhelpful and beyond its scope.

I also don't see why it is enabled when SKIP_PREFLIGHT_CHECK is true. I'm also confused about that flag's purpose as in the code it looks like it disables another, separate path to eslint & I don't understand why there are two.

Do we have a confirmation that this only happens for people with custom configs?

Do we have a confirmation that this only happens for people with custom configs?

If I get rid of .eslintrc.js, I see the "old" behavior of compiling with warnings. If I keep .eslintrc.js, any rules not set to "warn" in that file will result in "Failed to compile" with a listing of broken rules (the two rules I tested were no-unused-vars and no-debugger).

Do we have a confirmation that this only happens for people with custom configs?

I confirm for me too. In my case it come from my air-bnb extended eslint

Same for me as above. I commented out the air-bnb in the extend array, and things started working again.

+1 here on confirming the relationship to existing rules.

I have always had 'airbnb' in my extends list. It has been there for years on dozens of projects with CRA 3.

With CRA 4, it causes dev build to fail on unused variables. Removing airbnb fixes it.

I also get no-console complier error, I fixed it by remove the old eslintrc.js and overrides rules in package.json:

  "eslintConfig": {
    "extends": [],
    "overrides": [
      {
        "files": [
          "**/*.ts?(x)"
        ],
        "rules": {
          "no-console": "off"
        }
      }
    ]
  },

I'm also seeing this issue - unfortunately none of the suggested solutions work. I had briefly thought that @LuoTuxiu's suggestion worked, but that's because I forgot to include the offending file 🤦‍♂️

Since the issue fix is scheduled for 4.0.2 I used patch-package to create a temporary workaround. You can do the following to fix the issue:

1. Follow the steps at patch-package set-up section

2. In node_modules\react-scripts\config\webpack.config.js you can change the ESLintPlugin config to allow compiling when has eslint erros adding failOnError as false (I also added emitWarning as true to see errors in console):

     new ESLintPlugin({
        // Plugin options
        failOnError: false, // add this line
        emitWarning: true,  // add this line
        extensions: ['js', 'mjs', 'jsx', 'ts', 'tsx'],
        formatter: require.resolve('react-dev-utils/eslintFormatter'),
        eslintPath: require.resolve('eslint'),
        context: paths.appSrc,
        cache: true,
        // ESLint class options
        cwd: paths.appPath,
        resolvePluginsRelativeTo: __dirname,
        baseConfig: {
          extends: [require.resolve('eslint-config-react-app/base')],
          rules: {
            ...(!hasJsxRuntime && {
              'react/react-in-jsx-scope': 'error',
            }),
          },
        },
      }),

3. Then run npx patch-package react-scripts. This will create a patch to your project that whenever someone installs dependencies, it will change the webpack.config.js file at react-scripts folder.

Since the issue fix is scheduled for 4.0.2 I used patch-package to create a temporary workaround. You can do the following to fix the issue:

1. Follow the steps at patch-package set-up section
2. In node_modules\react-scripts\config\webpack.config.js you can change the ESLintPlugin config to allow compiling when has eslint erros adding failOnError as false (I also added emitWarning as true to see errors in console):

     new ESLintPlugin({
        // Plugin options
        failOnError: false, // add this line
        emitWarning: true,  // add this line
        extensions: ['js', 'mjs', 'jsx', 'ts', 'tsx'],
        formatter: require.resolve('react-dev-utils/eslintFormatter'),
        eslintPath: require.resolve('eslint'),
        context: paths.appSrc,
        cache: true,
        // ESLint class options
        cwd: paths.appPath,
        resolvePluginsRelativeTo: __dirname,
        baseConfig: {
          extends: [require.resolve('eslint-config-react-app/base')],
          rules: {
            ...(!hasJsxRuntime && {
              'react/react-in-jsx-scope': 'error',
            }),
          },
        },
      }),

1. Then run npx patch-package react-scripts. This will create a patch to your project that whenever someone installs dependencies, it will change the webpack.config.js file at react-scripts folder.

Thank you very much @fernandaad, this helped a lot!

Hi all, we've created a discussion around this - as we do plan to make changes soon. Please let us know what you'd like to prioritise, or if we've missed something.

See #10344

In our setup it looks like our .eslintrc.json is ignored by the build. Yet, it is properly applied in VSCode.

I also get no-console complier error, I fixed it by remove the old eslintrc.js and overrides rules in package.json:

  "eslintConfig": {
    "extends": [],
    "overrides": [
      {
        "files": [
          "**/*.ts?(x)"
        ],
        "rules": {
          "no-console": "off"
        }
      }
    ]
  },

Thanks, but I fixed it after adding something to the extends field based on your solution.

"extends": [
	"react-app",
	"react-app/jest"
],

Hi everyone, you can now change this behaviour as of the latest react-scripts release, 4.0.2. There are two new flags, ESLINT_NO_DEV_ERRORS and DISABLE_ESLINT_PLUGIN.

Please see the PR #10170 or docs for more info!
https://create-react-app.dev/docs/advanced-configuration/

Forgive me if this sounds naiive, I'm a little new to create-react-app, but does the configuration text mentioned in the CRA ESLint documentation go in .eslintrc.<whatever> or somewhere else? I'm a little confused because it doesn't quite look like that's an eslint config file of its own, with the "eslintConfig" key being at the root.

Forgive me if this sounds naiive, I'm a little new to create-react-app, but does the configuration text mentioned in the CRA ESLint documentation go in .eslintrc.<whatever> or somewhere else? I'm a little confused because it doesn't quite look like that's an eslint config file of its own, with the "eslintConfig" key being at the root.

Nevermind, I figured out it goes in package.json, I guess that makes sense.

@KyleRAnderson it can go in the root too if you prefer, as a valid ESLint config file.

Just keep in mind that the behaviour as of v4.0 is that your ESLint config is used within the Webpack ESLint Plugin, which means that errors will show in the error overlay (which is what this issue, and solution are about).

Awesome Work

Hi everyone, you can now change this behaviour as of the latest react-scripts release, 4.0.2. There are two new flags, ESLINT_NO_DEV_ERRORS and DISABLE_ESLINT_PLUGIN.

Please see the PR #10170 or docs for more info!
https://create-react-app.dev/docs/advanced-configuration/

Truly Awesome Work 👏🔥🔥

@KyleRAnderson it can go in the root too if you prefer, as a valid ESLint config file.

Just keep in mind that the behaviour as of v4.0 is that your ESLint config is used within the Webpack ESLint Plugin, which means that errors will show in the error overlay (which is what this issue, and solution are about).

Thank-you for clarifying, that makes a lot of sense, and thank-you for resolving this issue. It was something I was facing as well 😃

@mrmckeb possible related issue #10509

I'm also a bit new to CRA so I'm having troubles with this, I'm adding the new rule to my .env as says on the docs but when I try to run the dev server I keep geetting the errors that prevent the build. This is only happening with ESLINT_NO_DEV_ERRORS using DISABLE_ESLINT_PLUGIN does work. Thanks for the help

@CarlosHdez -- I'm seeing the exact same behavior.

I have two files, .env and .env.production which look like the following:

.env

SKIP_PREFLIGHT_CHECK=true
ESLINT_NO_DEV_ERRORS=true

.env.production

SKIP_PREFLIGHT_CHECK=true
ESLINT_NO_DEV_ERRORS=true
PUBLIC_URL=/my-app

Unfortunately the ESLINT_NO_DEV_ERRORS does not work, while DISABLE_ESLINT_PLUGIN does.

Thanks for reporting this @cjones26 and @CarlosHdez. Are either of you able to provide a reproduction of this?

Using react-scripts@4.0.2 I'm able to confirm that this works with a few errors/warnings, but it could be to do with the number of errors... Or something else might be at play.

In this example, I have one error, one warning. With this flag, both are now warnings

@mrmckeb for some reason, I can see that all errors became warnings with the new flag in the terminal, but it still throws the error on the app error overlay. That's the point of this issue.

@rus-yurchenko, this was supposed to fix that, I'm sorry if you aren't seeing it fixed.

Can you please share a screenshot, or some more details? A reproduction would be ideal :)

@mrmckeb I left a comment with a Codesandbox Container example where the problem metioned by @rus-yurchenko can be reproduced. You can see it here

Thanks @miguelCT. Interestingly I can reproduce with only some errors, not all (maybe only TypeScript-related errors).

I'll keep investigating. I see they also made changes to the way this works in the plugin itself, which I also need to dig into:
https://github.com/webpack-contrib/eslint-webpack-plugin/blob/master/CHANGELOG.md#250-2021-02-04

Thanks @miguelCT. Interestingly I can reproduce with only some errors, not all (maybe only TypeScript-related errors).

I'll keep investigating. I see they also made changes to the way this works in the plugin itself, which I also need to dig into:
https://github.com/webpack-contrib/eslint-webpack-plugin/blob/master/CHANGELOG.md#250-2021-02-04

Would it still be helpful if we provided an example, or is the example provided by @miguelCT sufficient?