Request: The LSP should generate diagnostics from the formatter

[In3luki]

For feature parity with the Prettier vscode extension it would be nice if Biome could also highlight lines that need formatting:

Edit: Looking at the screenshot again it may actually be the ESLint extension that emits the diagnostics but my point still stands. 😅

[ematipico]

Mmmmh, are you sure that's what you want? Apart from the feature parity, that diagnostic isn't that great because the text is cut.

We usually tend to use LSP diagnostics for messages that are more actionable. Do you have any other suggestions to make the diagnostic better?

[In3luki]

I don't think the text is cut off? The dots represent the indenation (as spaces) that will be added by the formatter. I might misunderstand what you mean.
For me personally it's a convenient way to see what is wrong with a file before it is altered by e.g. auto formatting on save.

If I want to ignore a problem I can add a // eslint-disable-next-line prettier/prettier comment via the Quick Fix context menu without having to undo the formatting of the whole file after it was formatted.
These are all the Quick Fix options for reference:

[martinbiard]

I was also looking for this for the Jetbrains IDEs as I prefer to disable any automatic formatting and see the issues flagged in the editor instead. The visual flagging of code that needs a reformat lets me know that there are issues and I remain in control to decide when to reformat the whole file, or only part of the code, using the Ctrl-Alt-L shortcut. When you are used to this visual feedback, it is hard to consider migrating to biome, which doesn't provide it.

Below is how I like to see those formatting issues in my editor.

[mdrobny]

Me and people at my company are also surprised to see that there is no visual information (highlight) about lines that need formatting.
In my opinion it's useful to see visually what code is following the formatting rules and what code violates it.

I am not used to switching between editor and terminal to check if code is formatted correctly. Maybe I need to learn it or enable formatting on file save but it's not obvious approach to me currently.
It would be also important when introducing new developers to the codebase so they can quickly learn about the formatting rules.

Biome is awesome 🚀 and I hope we can start using it in all projects but such small things are sometimes big blockers 😭

[ematipico]

The Biome formatter is closer to how editors (hence LSP) use it. Users configure the formatting as they wish (on save, on type, on select, etc.), and the editor takes care of the rest. The CLI is a safety net if users want to enforce it in CI.

We think formatting is not meant to be used as a lint rule.

Plus, having formatting as a lint rule could cause the following "problems":

• Degraded DX where multiple lines might have a red squiggle because something isn't formatted
• Having multiple actions that do the same thing could degrade the performance of the LSP. Multiple actions: the LSP formatting action and the inline formatting action
• Formatter and Linting suppression systems have different semantics. If we mix them, it could cause more confusion

Also, we try to look at other ecosystems (not just JS) for standards, and it seems that this is the way to go for Biome.

I'm sorry if this is a massive blocker for you; I just hope that you're open to embracing a different vision of formatting and linting.