After update to 4.0 lint errors are blocking the rendering

@unframework

Describe the bug

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

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: #9887 (comment)_

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.
Clean your code or change severity of eslint rules in your eslintrc file. (change them to warning for instance)

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.

fix: webpack ESLintPlugin honours SKIP_PREFLIGHT_CHECK (react#9887)

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

fix: webpack ESLintPlugin honours SKIP_PREFLIGHT_CHECK (react#9887)

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?

@mrmckeb

Hi @mrmckeb,

I'm not sure if the problem is related but upgrading to React 4.0.3 from 3.x gave us new errors blocking the build, same as the author of this thread.

While I'm not against blocking the build I don't understand why I cannot modify those errors in our eslintrc.json file.

It looks like upgrading to 4.X now ignore our local configuration. For exemple, adding "@typescript-eslint/ban-ts-ignore": "off", successfully removes the error from VScode but the build is still failing the same way.

@vincentdesmares

Hi @vincentdesmares, that sounds like a setup issue - as it definitely shouldn't behave that way - but it may be a bug of course! Can you share a reproduction? I can investigate further :)

I will try to reproduce the issue in a standalone repository.

I'm very tempted to just trash my previous config and start clean but right now if I want to configure my app, the only reference that I found is https://create-react-app.dev/docs/setting-up-your-editor and the emplacement of the configuration is not explicitly specified.

What's the available configurations?

It should be anything that ESLint supports: https://eslint.org/docs/2.0.0/user-guide/configuring#configuration-file-formats

Just make sure it's not defined in your package.json too - as that's where we place it by default.

Bump react-scripts to v4.0.3

I'm still getting this issue in 4.0.3 -

Failed to compile.

src/scripts/components/App.tsx
  Line 7:8:     'Loading' is defined but never used                            @typescript-eslint/no-unused-vars

@stclairdaniel

@stclairdaniel add ESLINT_NO_DEV_ERRORS=true in your .env, it will skip these errors in development

This still seems like an issue when building. ESLINT_NO_DEV_ERRORS=true fixes when simply running for development, but when building the build still fails on lint errors

This still seems like an issue when building. ESLINT_NO_DEV_ERRORS=true fixes when simply running for development, but when building the build still fails on lint errors

That’s the expected behavior. It’s the DEV in NO_DEV_ERRORS. If you don’t want a particular error to break your build, you can turn off the specific linting rule in your eslint config.

This still seems like an issue when building. ESLINT_NO_DEV_ERRORS=true fixes when simply running for development, but when building the build still fails on lint errors

That’s the expected behavior. It’s the DEV in NO_DEV_ERRORS. If you don’t want a particular error to break your build, you can turn off the specific linting rule in your eslint config.

Is there no build equivalent of ESLINT_NO_DEV_ERRORS? I don't want ANY lint errors to break my build, it's a style check, bad style should not be a reason for my deployment to suddenly be not building. I shouldn't have to go through and change all my lint rules to warning instead of errors, especially because then our CI workflow won't notify us of the lint "failure"

@Nerdsie

This still seems like an issue when building. ESLINT_NO_DEV_ERRORS=true fixes when simply running for development, but when building the build still fails on lint errors

That’s the expected behavior. It’s the DEV in NO_DEV_ERRORS. If you don’t want a particular error to break your build, you can turn off the specific linting rule in your eslint config.

Is there no build equivalent of ESLINT_NO_DEV_ERRORS? I don't want ANY lint errors to break my build, it's a style check, bad style should not be a reason for my deployment to suddenly be not building. I shouldn't have to go through and change all my lint rules to warning instead of errors, especially because then our CI workflow won't notify us of the lint "failure"

@Nerdsie There is. Check out this PR. The environment variable DISABLE_ESLINT_PLUGIN set to true will do what you want.

@rswerve

@rswerve Thanks, just what I need. It still feels weird to me to have to disable (both in prod and dev, via seperate options) build breaking on lint errors. Are people using eslint in such a way that lint errors catch more than just deviation from preferred styling?

@rswerve

@rswerve Thanks, just what I need. It still feels weird to me to have to disable (both in prod and dev, via seperate options) build breaking on lint errors. Are people using eslint in such a way that lint errors catch more than just deviation from preferred styling?

@Nerdsie Yes. For example, to enforce the Rules of Hooks. If someone wants to break one of those rules, we want them to be aware they're doing it and disable it deliberately, so we can see it in code review. And even with styling, on a team you're either enforcing consistent styles or you're not; we find it's less to think about if we are, so we break the build (this almost never happens, because everyone runs Prettier locally).

@rswerve

Confirming @rswerve solution, here is my build npm script:

"build": "npx tsc --noEmit && DISABLE_ESLINT_PLUGIN=true CI=false react-scripts build",

Navigation Menu

Repository navigation

After update to 4.0 lint errors are blocking the rendering #9887

Describe the bug

Expected behaviour

Edit:

Solutions & workarounds

76 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

After update to 4.0 lint errors are blocking the rendering #9887

Description

Describe the bug

Expected behaviour

Edit:

Solutions & workarounds

Activity

dev-bjoern commented on Oct 24, 2020

mstykow commented on Oct 24, 2020

fred172 commented on Oct 26, 2020

RosenTomov commented on Oct 26, 2020

Saibamen commented on Oct 26, 2020

rus-yurchenko commented on Oct 26, 2020

RosenTomov commented on Oct 26, 2020

Saibamen commented on Oct 26, 2020

asdfasdfasdfasdfff commented on Oct 27, 2020

abraidwood commented on Oct 27, 2020

fredefl commented on Oct 27, 2020

76 remaining items

vincentdesmares commented on Feb 25, 2021

mrmckeb commented on Feb 26, 2021

vincentdesmares commented on Feb 26, 2021

mrmckeb commented on Feb 26, 2021

stclairdaniel commented on May 12, 2021

anushbmx commented on May 13, 2021

Nerdsie commented on Jun 4, 2021

rswerve commented on Jun 4, 2021

Nerdsie commented on Jun 4, 2021

rswerve commented on Jun 4, 2021

Nerdsie commented on Jun 4, 2021

rswerve commented on Jun 4, 2021

soullivaneuh commented on Jun 30, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions