FR: Add more diagnostic levels than "warn" and "error"

[chrisgrieser]

Linters and LSPs commonly also support "info" or sometimes "hint" as a diagnostic level.

It would be useful to allow biome to add those as well. Having more diagnostic levels is useful for various reasons, e.g. filtering diagnostics or visually different emphasis.

[ematipico]

Would you happen to have a specific suggestion in mind? We haven't encountered any use case where we can emit a hint and info so far

[chrisgrieser]

Some rules where I personally would use an info diagnostic level, and which might maybe make sense to have info as default, are rules related to casing, console or unused…. This can be understood by thinking about what type of information diagnostic levels convey:

• error usually means that there is an issue which throw an error or otherwise disrupt the execution of a program in an unrecoverable way. Rules like noDelete, which state "this can cause unexpected behavior" fit well here.
• warning conveys that some code can be a problem, or would seriously decrease readability, resulting in issues later on. Using let instead of const for a variable that isn't changed would fall in this category.
• info that will neither cause an error, and even would not disrupt program execution in any way. It should be assigned to issues which may be a problem, but could also be unproblematic.
  • Casing-related rules namingConventions is something that I could think of here, since using e.g. snake_case instead of camelCase will not result in errors or disrupt program execution, but is more a convention for consistency.
  • noConsoleLog would also be a rule I'd assign info to, since log statements are often actually desired, and having log statements left over never really causes trouble of any sort – the rule mostly exists as a reminder to not forget to clean up such statements.
  • The Lua LSP, for example, assigns info by default to diagnostics related to unused[variable|parameter|function], probably also following the heuristic of an issue which does not cause problems during runtime, but are mostly information that you forget to clean up something.

---

A practical example could be assigning noConsoleLog the info diagnostic level, and configuring the IDE to only display warnings and errors, but have a pre-commit-hook with biome report everything. That way, the IDE is not littered with diagnostics when you are currently debugging an issue by using log-statements. But by having the pre-commit hook include noConsoleLog, it will nonetheless warn me if you forgot to remove the log-statements after resolving the bug.

Technically, you could of course handle such situations by using two config files, but that would create the burden of keeping two config files in sync. You could also just display errors in the IDE, and display errors and warnings in the pre-commit hook, excluding all warnings may be a bit too much, since there are many issues you'd want to have reported right away and not only when committing. An info diagnostic level is not a hard requirement for sure, but would it be very convenient to have for various cases.

---

A very conservative solution could be to just add info as an available diagnostic level, but not use it as a default level for any rule. That way, users have the option to assign info to particular rules in their config if they find it useful, without changing anything for the remaining users.

[Conaclos]

Biome 1.8 added the info level.

[chrisgrieser]

Thank you very much!