How to prevent failing to compile on CRA when eslint errors?

[a-tonchev]

I installed the new react/CRA version (4). Right now when I have eslint errors the whole page blows and CRA fails to compile.

Sometimes I make some small test or debug something in the flow, and don't want CRA to fail the running only because of 1-2 intentional eslint errors.

Is there a possibility only to display the errors in the console, but not to fail to compile?

If it fails the npm run build it is okay.

Thanks and best regards

[pascalstr]

Add additional rules to your eslint configuration, it will overwrite error to warn. You have to specify it per rule.

rules: {
    "@typescript-eslint/no-unused-vars": ["warn"],
    ...

[a-tonchev]

Hmm thanks, this is a kind of workaround, but I don't see it as real solution...

[chrisahardie]

The issue with this workaround is that I extend multiple configs... I'd have to override a non-trivial number of rules.

In my case, the ideal would be to apply something like the now-deprecated eslint-loader's emitWarning: true during development. Otherwise without overriding many, many rules, and even with Format on Save applied in my IDE, I am having to spend time fixing eslint errors for code that I am experimenting with and may never actually want to keep.

Only when I run a husky hook or in a pre-build step do I want to run a strict check with an NPM script like: "lint": "eslint --max-warnings 0 --ext .tsx,.ts ./src"

[brumm]

This is our exact issue as well. We updated from 3.4.3 and having the build fail for a stray unused import during development is almost hostile. There really should be an option to restore previous behavior.

[cdavid15]

This is our exact issue as well. We updated from 3.4.3 and having the build fail for a stray unused import during development is almost hostile. There really should be an option to restore previous behavior.

Couldn't agree more with this. Local development workflow now shot to pieces with this now

[gaving]

Burned by this since upgrading today, odd default for a development env.

[chrisahardie]

This page has a comment which describes the desired behaviour from CRA < 4:

// We use eslint-loader so even warnings are very visible.
// This is why we prefer to use "WARNING" level for potential errors,
// and we try not to use "ERROR" level at all.

Was there a conscious decision to change this behaviour, or was it just left out of the new linting configuration during the migration away from eslint-loader?

[kagant15]

This is a big stopper for me (and most likely for anyone else who extends CRA linting rules beyong it's default). Unless a solution is provied I'll have to revert to a pre 4.0 version. Even doing something as simple as extending eslint's react-app with airbnb will cause a compile error on things that were perviously harmless warnings.

[gone-skiing]

Team, we are blocked by this as well. Do we have any more insight into what is going on here? What is the rational for failing the build on warnings? It would be good to know the background before we come up with next steps.

We have a large codebase that predates the introduction of eslint and a richer rule set. We keep warnings on to help with on-going clean up without failing builds.

[NicoAdrian]

Local development went from smooth to painful. Litteraly have to wait 10 sec for every change made because I added an extra space in my code somewhere and it doesn't compile. Can't debug properly. Rollbacking

[Lulololu]

Look at this issue : #9887

As they say, commenting out airbnb mentions in the extends array make things work again....

[NicoAdrian]

I don't even have airbnb in the extends array in my eslintrc config.

I have only have:

• eslint:recommended
• plugin:react/recommended
• plugin:prettier/recommended

[chrisahardie]

@NicoAdrian If you look at the eslint:recommended config, all rules are errors. You would need to override all of them locally - and all other errors in any other config - and turn them into warnings instead to prevent any error from blocking compilation.

[NicoAdrian]

@chrisahardie Linting errors didn't block me from compiling before 4.0.0, I don't plan to override settings

[Kaschman]

Having the same issue on my team - we want to enforce linting at commit/PR time, but not during active development. We would really like to ignore lint errors when running start but still keep those rules as errors in our lint config for use in a precommit hook or CI process.

I noticed under advanced configuration there is an option to compile despite having Typescript errors - TSC_COMPILE_ON_ERROR. Having a similar option for lint would be tremendous - something like LINT_COMPILE_ON_ERROR that we could set when this behavior is desired.

[iamyojimbo]

Used to work out the box, in the true style of CTA, now it doesn't.

[rpilev]

This is completely unreasonable in my opinion as well. I think our team also has no choice but to just roll back and wait for them to change this behavior.

[chrisahardie]

This issue is a duplicate of: #9887

[webarnes]

@pascalstr's workaround is a decent option. If you're not using typescript, add something like the following in .eslintrc.json:

{
  "rules": {
    "no-unused-vars": "warn",
    "react/prop-types": "warn"
  }
}

In my case, it's only these two that are showstoppers. It's sub-optimal and I agree with the comments above that refusing to compile in the development environment over an unused variable is pretty hostile. But you'll at least be able to compile and it's simpler than holding back indefinitely.

[taschetto]

@webarnes but this will affect when you really want to lint your project, right? How can we configure a set of rules only for CRA that won't affect linting on CI for example?

[webarnes]

You can write eslintrc in Javascript and export a different object in different environments. So you would have different rules in development vs. production. Again, just a stopgap. I think the real solution would be saner defaults in CRA but I also want to keep working.

[ianschmitz]

Sorry you're running into this. It sounds like a duplicate of #9887. Let's consolidate the information over there if possible. Thanks!

[niyodusengaclement]

Sorry for being late but I think this can help others will have the same issue in the future
I only put this line ESLINT_NO_DEV_ERRORS=true in .env and worked as I expected

[a-tonchev]

@niyodusengaclement Thanks, this do the job indeed!

[AlexisLessard]

I've done the same in my package.json, like so:

 "scripts": {
    "start": "ESLINT_NO_DEV_ERRORS='true' BROWSER=none PORT=8080 react-scripts start",
  },

And now I can run the app with npm start. However, we can't build it to send it to production. We have a lot on errors and warnings, and we do plan on fixing em. We are fixing our codebase from the ground up, and a lot remains to be cleaned, but the app is functional, and can be shipped. However, it's impossible right now, because of the build.

Looking at the node_modules/react-scripts/config/webpack.config.js file, I understand how the failOnError parameter is configured. It's at false only if it's in development AND we have the variable set. But temporaly, I want this parameter to be at true even while we create our production build. Is that possible? Can we overload part of the webpack.config.js file in our project?

EDIT
Found a workaround. Obviously, it shouldn't be permanent, but this is the only way we have at the moment to make the build work. I DO NOT RECOMMEND IT IF YOU CAN AVOID IT! If you only have a couple errors and warning, now's the time to clean em! If you have a few hundreds... yeah, do that, but clean em reaaaal fast.

In the package.json file, add these variables to your start and build script:

 "scripts": {
    "start": "ESLINT_NO_DEV_ERRORS='true'  react-scripts start",
    "build": "DISABLE_ESLINT_PLUGIN='true' react-scripts build",
  },

The eslint will be completely disabled on your build. No warnings and errors. Use carefully.

[PaulHaze]

 "scripts": {
    "start": "ESLINT_NO_DEV_ERRORS='true'  react-scripts start",
    "build": "DISABLE_ESLINT_PLUGIN='true' react-scripts build",
  },

Thanks, Ive been using Vite for a while and went back to CRA just to build a starter skeleton for projects that Vite can't handle and forgot how annoying that problem was and how it seems it still hasn't got a satisfactory fix yet! Your solution did the trick for now though.... thanks....

[a-tonchev]

@PaulHaze I also switched to Vite, can you share what is possible at CRA, that can not be made with Vite? Just out of curiosity...

[PaulHaze]

@PaulHaze I also switched to Vite, can you share what is possible at CRA, that can not be made with Vite? Just out of curiosity...

Gosh I am probably the wrong person to ask. I'm still very much a beginner when it comes to programming. Especially compared to most people on here. My experience so far with Vite has been great though. Super fast, and feels a less bloated than CRA. Saying that I was working on one project with tailwind in Vite and the refresh was very slow and flickering on every save. For that one I went back to CRA and it worked fine. However since that project the issue hasn't returned and so far its playing nice with every tailwind build I've made with it.....

[hejuhenryk]

I create .env file and I am keep getting
Compiled with warnings. Line 4:2: Delete · prettier/prettier Line 5:3: Delete·· prettier/prettier Line 6:1: Delete· prettier/prettier
Is it how it should be or I am doing something wrong?

[inioluwa-io]

I fixed mine by adding ESLINT_NO_DEV_ERRORS=true and DISABLE_ESLINT_PLUGIN=true to .env, .env.development and env.production files

[Rohitbels]

Install
https://github.com/bfanger/eslint-plugin-only-warn

Add only-warn to the plugins section of your .eslintrc configuration file:

{
  "plugins": ["only-warn"]
}

[jessewriter]

Failed to load plugin 'only-warn' declared in '.eslintrc.js': Cannot find module 'eslint-plugin-only-warn'