Why disable `console.log`?

[mtchllbrrn]

I'm a fan of most of what I see, but I don't particularly understand the decision to disallow console.log. I can understand the "it has no place in production" argument, but I also wouldn't want my linter constantly complaining in a development environment.

[ljharb]

linters are typically run as part of tests. in development, while you might integrate them into an IDE or editor, that just means the console.log line will have a helpful error next to it reminding you to clean it up.

Alternatively, you could use the actual debugger for development.

Please feel free to fork the style guide and change any rules you like!

[mtchllbrrn]

This makes sense, and it's easy enough to override for my needs. Thanks for the quick response.

[rhbecker]

I assume this issue was raised with respect to eslint-config-airbnb, and the 'no-console': 1 found in rules/errors.js?

While my personal preference is to disallow use of console, I'd think the linter rules should align with what's explicitly stated in the style guide. I've looked through both the main README.md and the legacy es5/README.md, and neither mention whether or not to use console.

Along those same lines, eslint-config-airbnb/index.js extends rules/strict, which disallows use strict statements - similarly not corresponding to any statements in the style guide. Further exacerbating the issue, the non-eslint configs enforce use of use strict; see: .jshintrc and SublimeLinter.sublime-settings.

I see through the comments in that file that you have babel taking care of that responsibility. That certainly makes sense from an implementation perspective, but I'm not sure it belongs in the default shared config, unless you want to add babel usage to the style guide. If it were me, I'd probably ditch the rules/strict file in favor of a babel-users.js config at the root of the eslint-config-airbnb project. It could extend index.js, and could include a rules object with that 'strict': [2, 'never'] statement.

These findings make me wonder whether other rules are being enforced that aren't in alignment with the style guide. Given that each rule in the guide has a referenceable index (e.g. 1.2, 7.4, etc.), and given that each eslint rule declaration has a comment, might it be worthwhile to add the former to the latter? It would certainly clear up any confusion around why a rule exists, and would enable users to more easily spot disparities. An ambitious sort could probably even whip up a parsing script to look for unaccounted for style guide rules, eslint rules that are missing a guide reference, or eslint rules pointing to a non-existent reference index.

[ljharb]

@rhbecker absolutely the eslint config and the styleguide should be in sync. console should never be permitted in production code, so a PR to add that into the styleguide, and link to the rule, would be great!

Similarly, adding comments in the rule configs that point to guide sections would also be a very welcome PR.

[rhbecker]

@ljharb

adding console guidance to the style guide

Are there any instructions for contributing additions / edits to the guide text?

For example, I don't see an existing section that this addition would belong within. So, would I add a new section? If so, would I just add it to the bottom, or would I squeeze in between existing sections? The latter seemingly makes more sense, but doing so would require bumping all of the numbering in the subsequent sections, which would be a pita with respect to my cross-referencing idea over in the eslint config comments.

Also, if the guide is going to instruct against using console, it should probably offer guidance around alternatives. Do you follow any particular standard practice for common console use cases?

adding guide index references to eslint config comments

This one seems more my speed (I'm not much of a guide writer), but the issue I mentioned above makes me hesitant to invest time in this - i.e. if guide index numbers are going to get constantly bumped by contributors, and without guidance from the stewards, the comment references are going to get really useless, really fast.

regarding strict?

What are your thoughts on the suggestions I made for tweaking how you reflect your usage of babel? This one seems the most straight-forward for me to PR.

[ljharb]

It's kind of a judgement call - although yes, we don't want to change numbering because that would break links.

Why would there be an alternative in production code to debugging statements?

It'd be great to move away from numbers, so that reorganization doesn't break links.

You're welcome to open a PR so it can be discussed - I don't really think it's needed though. Using ES6 without babel isn't realistic at this point.

[rhbecker]

It's kind of a judgement call - although yes, we don't want to change numbering because that would break links. [...] It'd be great to move away from numbers, so that reorganization doesn't break links.

So, I'm not sure what to do here, then. Any ideas?

Why would there be an alternative in production code to debugging statements?

Some folks may be using console.log() or console.error() statements within a node.js app in order to log to app or error log files, or to return responses to stdout / stderr for cli apps. Suggesting a "good" approach seems to be a theme in the guide. If you think it's sufficient to simply instruct against, I can be fine with that.

You're welcome to open a PR so it can be discussed - I don't really think it's needed though. Using ES6 without babel isn't realistic at this point.

Fair point - I'm just opposed to rules in default that don't correspond to stated guidance. It blurs the lines as to whether the shared eslint config reflects the guide or the usage of the guide by airbnb. Perhaps adding guidance is the better approach here, but seemingly one or the other should happen.

[tylerlong]

@ljharb

console should never be permitted in production code

What if my product is a command line tool? Like a clone of grep in node.js. Without console, how can I output information to the console?

[ljharb]

@tylerlong in that case, you'd want to override this rule for your specific project. Linter configs and styleguides should cover the majority case, and individual projects can and should conscientiously choose which things to deviate from and/or override.

[polarstoat]

Is there any way the no-console rule could be disabled when the node environment is set then?

[ljharb]

@polarstoat sure, when you set the environment, then you also override the rule. There's no way for rules to check the environment settings that I know of.

[kasperpeulen]

I don't understand this rule. I thought console.debug was meant for debugging, messages that should be removed later.

But why would there be no place for console.info or console.warn in production apps?

For example create react app uses console.warn to show eslint warnings in the console.

[ljharb]

@kasperpeulen rules are for production. You can simply ignore the error in development.

The reason you wouldn't want them in production is because not every browser has a console, and calling console.info will throw an error in that case.

[kasperpeulen]

The reason you wouldn't want them in production is because not every browser has a console, and calling console.info will throw an error in that case.

In which browser does this give an error?

[ljharb]

@kasperpeulen IE 6-8, for one. Likely non-Chrome Android browsers as well.

[PolGuixe]

@ljharb which is the best way to report a warning or info, or to log any information in production?

[ljharb]

@PolGuixe warnings should be caught in dev/test; and any info you want to log in production should be reported back to your server somehow, not just thrown into the abyss of browser consoles.

[ericksprengel]

My 2 cents to contribute to this discussion.

If your are developing a complex system, start adding logs keeping in mind a future debug. As @ljharb explained, if it doesn't cover your case, just change the rule.

Just to encourage those who need it... keep reading... I worked for some years on Android OS and I can say for sure without any log it's impossible to investigate some issues. Fortunately the Android OS has many logs ( about 6201 only in AOSP source code[1] ) In short, I know that just logging many things in the console sounds weird, but in the future it can save many time while debugging. If developers never commit any log, it'll be not easy to start an investigation in the future. Be careful to not log sensitive info or to log a lot of useless info. Just be happy 😄

[1] Android XRef search: http://androidxref.com/9.0.0_r3/search?q=%22Log.i%22+OR+%22Log.d%22+OR+%22Log.w%22&defs=&refs=&path=&hist=&project=art&project=bionic&project=bootable&project=build&project=compatibility&project=cts&project=dalvik&project=developers&project=development&project=device&project=external&project=frameworks&project=hardware&project=kernel&project=libcore&project=libnativehelper&project=packages&project=pdk&project=platform_testing&project=prebuilts&project=sdk&project=system&project=test&project=toolchain&project=tools

[ljharb]

If tests are thorough enough, logs aren’t needed once it’s shipped.