Suggestion to remove "no-console" from "recommended" rules
See original GitHub issueFirst off, thanks for eslint. It is an amazing tool that helps me catch issues in my code. I use it in every JS project I create. Much ❤️ to the team for all the bugs you’ve helped me prevent.
I enjoy using the recommended
rules to help me catch issues, without adding stylistic or opinionated rules. However, I feel no-console
should be removed from the recommended
setting because I feel it is more commonly a feature and tool than a potential issue. It’s true that leaving console output in production websites can be an issue, but this is a feature in other environments like node. It is extremely common to build node scripts and CLIs using console output as a feature. And even for websites, using console output is extremely common to aid in debugging - having console output show as a lint error while debugging is distracting. I understand that any rule can be negated with rules
config, but in my opinion the recommended
rules should stick to only potential issues in code, which I don’t think console output is.
It seems some others agree. For example, create-react-app doesn’t use recommended
for a couple reasons - one of which is this issue - as Dan Abramov explained here: https://github.com/facebookincubator/create-react-app/issues/11#issuecomment-235543462. I would imagine if there was a poll given that the majority would agree and would encourage that be done if possible.
Another option would be to keep the console.log
error in recommended but allow the more deliberate console.info/warn/error
options by default:
"no-console": [
"error",
{
allow: ["info", "warn", "error"]
}
],
Anyways, my 2 cents. Will be interested in discussing and others opinions. Thank you for your time.
_Started because of twitter thread: https://twitter.com/geteslint/status/860270285047582720_
Issue Analytics
- State:
- Created 6 years ago
- Reactions:5
- Comments:13 (5 by maintainers)
As I mentioned before, for me, having arbitrary logging isn’t useful in the long run and any long-term logging should be tagged and organised for maintainability (which is usually what logging libraries provide).
Allowing info/warn/error will just make someone go into the habit of using
console.info
to easily bypass the linter.Actually, I’m going to re-open this to consider a suggestion: what if the default for
no-console
were changed to:That way,
console.log
s still throw an error, but deliberate logging (console.info
,console.warn
andconsole.error
were allowed by default?