noConsole vs noConsoleLog?

[drwpow]

Biome has a noConsoleLog rule, as opposed to ESLint’s no-console rule. The former only warns/errs on console.log() literally. But the no-console rule warns/errs on console.error, console.warn, and console.debug as well:

Biome noConsoleLog

ESLint no-console

My question is: should Biome get additional lint rules like noConsoleError to handle the other cases? Or does Biome just need a noConsole rule to warn/err on all of them collectively?

Or is the single noConsoleLog rule intentional, going off the assumption that it’s mostly console.log that’s used by accident and the other ones are intentional, so there’s no need to make rules for them?

[ematipico]

@anonrig what's your take here? I would love to have your thoughts here.

[Conaclos]

Usually developers use console.log to debug their code.
Other methods such as console.info, console.warn and console.error are used to log information, warnings, and errors.

I implemented noConsoleLog to warn against debugging code.
Therefore, the rule doesn't warn about other uses of console.

However, some users/contributors, such as @anonrig, want to warn against other uses of console.
I am not sure of the reasoning behind this.
@anonrig has implemented [noConsole] (https://biomejs.dev/linter/rules/no-console).
The plan is to add an option to whitelist some uses.
We could deprecate noConsoleLog once noConsole is stabilized.

[Conaclos]

@drwpow what behavior do you want?

[drwpow]

noConsole would work for me! That would probably be simplest as it maintains parity with no-console.

Just speaking personally, I have 2 main usecases where I enforce this rule:

1. I’m writing browser code, and it’s just bad form to clutter up the user’s console with non-essential information (i.e. devs should have an explanation why logging to the browser console is necessary)
2. I’m writing a Node.js CLI utility, and I need to be conscious of when/where I’m logging to the console because I may need to preserve stdout as the output of a function (and not just diagnostics).

In both scenarios, I want to catch log/debug/warn/error indiscriminately, which noConsole would do nicely for. Though I’m sure there are some usecases where someone may be concerned with individual logging methods, I personally don’t need it.