Create-react-app: After update to 4.0 lint errors are blocking the rendering

Created on 24 Oct 2020  ·  22Comments  ·  Source: facebook/create-react-app

Describe the bug

With CRA 3.x lint errors where reported as warning in the console. Now it is blocking the rendering :
image

Expected behaviour

I would like to have by default the old behaviour (warning in console), or at least a way to switch back to this old behaviour


Edit:

@unframework give bellow a nice analysis about this issue: https://github.com/facebook/create-react-app/issues/9887#issuecomment-720902192_

Solutions & workarounds

  • Implement a way to disable eslint in CRA builds/dev (env variables ...)
  • Use two eslint config files. One for text editor, and one for React.
bug report needs triage

Most helpful comment

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 https://github.com/facebook/create-react-app/pull/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.

All 22 comments

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.

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 https://github.com/abraidwood/create-react-app/commit/39452dfe5d1974ee88314a673e11fda7a0a0a811

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 https://github.com/facebook/create-react-app/pull/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 🤦‍♂️

Updated to CRA v4 and started running into this as well. We have a more restrictive .eslintrc that was used to keep things like unintentional debugger and log statements out of production builds. But now those are throwing compile errors during the normal development process, which is rather cumbersome and slows things down.

We're going with a modified version of @jrr 's "terrible, no good, really bad workaround" conditional config fix for now to allow us to use the more restrictive config only in our CI builds.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

DaveLindberg picture DaveLindberg  ·  3Comments

wereHamster picture wereHamster  ·  3Comments

rdamian3 picture rdamian3  ·  3Comments

dualcnhq picture dualcnhq  ·  3Comments

xgqfrms-GitHub picture xgqfrms-GitHub  ·  3Comments