Biome does not lint formatting

[erwanlpfr]

Hello,

We planned to use BiomeJS in replacement of ESlint.
We are actually facing an issue. Biome does not lint formatting issues :

{
	"$schema": "https://biomejs.dev/schemas/1.7.1/schema.json",
	"organizeImports": {
		"enabled": true
	},
	"linter": {
		"enabled": true,
		"rules": {
			"all": true
		}
	},
	"formatter": {
		"enabled": true,
		"indentStyle": "space",
		"indentWidth": 2,
		"lineWidth": 100
	}
}

This simple config file works well for most of the rules we need.
But when I mess up a react code to look flat, I have no feedback of Biome to tell me that my code is not valid.
Since, yes, indentations problem is an error.

Do you have an idea of to show this kind of issue in the linter on VSCode?

Thank you!

[nhedger]

If you're referring to rendering squiggly lines when the format is incorrect, you're right.

Biome currently does not report diagnostics for formatting differences.

Usually, people enable format on save, which takes care of it automatically.

[erwanlpfr]

Okay, makes sense !
Thank you for your answer, we'll take in account. Biome is that fast that we'll use it for sure.

Do you think therr is any plan ?

[ematipico]

No, we don't have any plans for that

[erwanlpfr]

Thank you for your replies !

[ViggoV]

This is probably gonna be a deal breaker for me. Is there any reason why you wouldn't want to support that?
It may be a personal preference and/or anxiety trigger, but a tool automatically mangling my code (however reasonable the changes may be) is a lot easier to swallow if it warns me in advance... Also this is an excellent opportunity to learn if you can inspect which rule is being broken and why.

I currently use eslint with eslint-plugin-prettier, which does exactly that

[ematipico]

Biome infrastructure is mostly aligned with how IDEs (LSP) work, where the formatting action is set up in your editor, and since formatting is a harmless action that doesn't change the semantics of your code, so it doesn't require a diagnostic inside the editor.

Making a non-formatted code a lint rule is kinda an anti-pattern, in fact the diagnostics emitted by that plugin can be slow - mostly because you have to calculate all the ranges/spans where the code is different -, and full of text because formatting can be invasive (imagine when paste some code, and the indentation is all wrong).

You can still enforce formatting code in CI via CLI, however we decided to align the flow with IDEs. I hope you'll reconsider your position. If that's still a deal breaker, maybe prettier+eslint+plugin is the tool for you

[vitexikora]

Wow, did not expect this at all.

Formatting is very important to be consistent in all code, otherwise it can cause troubles merging code & doing codereviews (too many changed lines just due to formatting, hard to find actual code changes).
So just one developer not using an extension to format on save could cause trouble.

The only option to solve this would be a pre-commit hook, but that can cause mess if you sometime need to first commit an invalid code (eg. while doing some multi-step git operation). Doing it in CI would work, but some junior devs dont push to CI or just do not have granted access to it.

Really, what about something like { formatter: { enforceErrors: boolean } } ?
This would solve it all and could be false by default.

[vitexikora]

We are staying with Biome, since it is just so much faster, but in the format linting, it is a significant downgrade from eslint :(
Our codebase is semicolon-free and Biome wont even highlight it, if someone adds one (eg. when copying code).
Much anticipated tool to migrate to ended up as partial disappointment.

[Necrelox]

I really wanted to migrate, but this issue blocked me too. I'm not a fan of auto-formatting, I prefer doing a manual "fix all" pass.

The fact that formatting issues (indentation, semicolons, etc.) aren't treated as real lint errors was a dealbreaker for me.
I had to cancel the migration because of that. I'm honestly disappointed, because I had high hopes for this tool, it could've replaced the nightmare that is ESLint with its endless list of packages

Please consider reconsidering this behavior 🥺

[vitexikora]

Yeah I was really on the brink of cancelling the migration, so angry they decided this to be not configurable. Only because ESLint is just so bad I decided to proceed with all our company projects. Eventually, I got used to it but really they should make sure that people who migrate, don't downgrade in some areas. It is very disappointing and makes you question the decision.