You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Only show lint warnings from most recently edited file in browser console #2378
I'm wondering if this helps with the complaint from tnrich in that linked thread. If the developer is commenting out stuff or w/e, saving and looking back to the browser - the changes (and thus, the output that annoys him) is going to come from that last edited file. Aren't those errors the ones he doesn't want to see in the console?
Wouldn't that be confusing if you have more than five and are only displaying five of them? As in, wouldn't capping the number defeat the purpose of having them there in the first place? I guess my pondering is whether displaying the linting errors in the console is to let the user know that he HAS errors or that he has these EXACT errors. I'm wondering if we should leave this alone and let it stay as is :)
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs.
can we just have an option to disable eslint console logs and that's it? I use eslint in IDE setup, it's logging stuff on terminal, errors are shown full screen, during build it logs errors on build machine and stops the production build if there are issues but polluting console with all those warnings is just a mess in my case. I need those warnings in IDE to highlight potential issues, but mostly i don't care about that warning. I use eslint to warn about sketchy code and throw errors about code which is potentially broken or may be broken in some case.
Could be an option to enable eslint
logs in console - all | warning | error | none
in cli - all | warning | error | none
and default is whatever is now, but there would be a way to disable.
and whatever extras like "recent file only" "limit to 5 warnings per file" and so on are just extension on main options - to log or not to log those warning at all
Huge +1 to @liesislukas. I tried to configure my webpack config through react-app-rewired to disable warnings on hot reload without much success. I wonder if this is because react-dev-utils uses its own webpackHotDevClient.
From what I've seen, people in my team interact with lints in the editor first, the "Problems" tab on VSCode second and the terminal third— not the browser. I don't doubt this might be useful for some people, but for us it in fact detrimental, since we do a lot of our debugging via console logging.
Rather than blocking a solution on the harder problem of filtering by recently-edited files, some immediate impact for many teams like mine would be an environment flag or some other mechanism to disable warnings in the browser outright.
I'm so slowed down by this I'd be happy to add a flag for disabling the relay of warnings. Where can I learn about the HMR system and how to disable warnings @gaearon?
Activity
siggirh commentedon May 29, 2017
I'm wondering if this helps with the complaint from tnrich in that linked thread. If the developer is commenting out stuff or w/e, saving and looking back to the browser - the changes (and thus, the output that annoys him) is going to come from that last edited file. Aren't those errors the ones he doesn't want to see in the console?
gaearon commentedon May 29, 2017
We can cap it to maximum 5 warnings per file, for example. They would still be there but they would be more relevant, and limited.
siggirh commentedon May 29, 2017
Wouldn't that be confusing if you have more than five and are only displaying five of them? As in, wouldn't capping the number defeat the purpose of having them there in the first place? I guess my pondering is whether displaying the linting errors in the console is to let the user know that he HAS errors or that he has these EXACT errors. I'm wondering if we should leave this alone and let it stay as is :)
gaearon commentedon May 29, 2017
We can debate whether to cap them or not, but I think displaying them just for most recently edited file is a good start by itself.
svicalifornia commentedon Aug 14, 2017
@gaearon @kombucha Has the commit referenced above been merged into the official CRA trunk?
kombucha commentedon Aug 16, 2017
@svicalifornia Nope, see #2409
gaearon commentedon Aug 17, 2017
Not yet. We'll do a cleanup pass some time after releasing React 16. For now most of my effort is focused on React.
stale commentedon Nov 2, 2018
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs.
svicalifornia commentedon Nov 5, 2018
@gaearon Now that React 16 and CRA 2 are out, can we revisit this issue?
roramigator commentedon Sep 13, 2020
Is this being worked on?
liesislukas commentedon Aug 27, 2021
can we just have an option to disable eslint console logs and that's it? I use eslint in IDE setup, it's logging stuff on terminal, errors are shown full screen, during build it logs errors on build machine and stops the production build if there are issues but polluting console with all those warnings is just a mess in my case. I need those warnings in IDE to highlight potential issues, but mostly i don't care about that warning. I use eslint to warn about sketchy code and throw errors about code which is potentially broken or may be broken in some case.
Could be an option to enable eslint
logs in console -
all | warning | error | nonein cli -
all | warning | error | noneand default is whatever is now, but there would be a way to disable.
and whatever extras like "recent file only" "limit to 5 warnings per file" and so on are just extension on main options - to log or not to log those warning at all
mrkev commentedon Sep 3, 2021
Huge +1 to @liesislukas. I tried to configure my webpack config through
react-app-rewiredto disable warnings on hot reload without much success. I wonder if this is becausereact-dev-utilsuses its ownwebpackHotDevClient.From what I've seen, people in my team interact with lints in the editor first, the "Problems" tab on VSCode second and the terminal third— not the browser. I don't doubt this might be useful for some people, but for us it in fact detrimental, since we do a lot of our debugging via console logging.
Rather than blocking a solution on the harder problem of filtering by recently-edited files, some immediate impact for many teams like mine would be an environment flag or some other mechanism to disable warnings in the browser outright.
I'm so slowed down by this I'd be happy to add a flag for disabling the relay of warnings. Where can I learn about the HMR system and how to disable warnings @gaearon?