Add Biome Linting Support

[jdsee]

Hi 👋

if I am not mistaken, the Biome-Formatter in Spotless currently only supports formatting but doesn’t check or apply linting rules. It would be great if the integration could support Biome’s linting as well to enforce the same rules as the referenced biome.json.

I think at the moment Spotless only runs biome format. To check the Linting as well we'd need to run biome check instead.

Thanks for considering this (or telling me that there's a configuration option that i missed 😆 )!

Cheers, Joscha

[blutorange]

I did that intentionally when I added biome integration, since spotless is a formatter. On a technical level, it shouldn't be a problem to run the linter and apply the autofixes.

On a conceptual level, I'm not sure. As I said, spotless is a formatter. I've seen some ideas to integrate linting with spotless, see e.g. #1097 #2149

Personally I wouldn't mind adding an option for applying autofixable linter fixes. That feels in the spirit of formatting. Erroring when a manual fix is needed does not sound right to me though. I wonder what @nedtwigg thinks about applying auto fixable linter fixes in spotless?

[jdsee]

Thanks for the clarification. The diktat integration checks linting as well as formatting, so I was hoping other formatters/linters would too.

Our main use case for Spotless is enforcing formatting/linting in CI/CD with one tool. Manually checking Biome in a separate step defeats that purpose a bit.

It'd be really great if we could configure the biome integration to check the linting rules as well. I understand that Spotless doesn't support Linting as a standalone concept yet, but maybe reporting linting errors through the formatting channel (as done for detekt, i suspect). Making it opt-in shouldn't hurt anyone.

[blutorange]

I haven't used Diktat yet, so I don't know what it does exactly. Just to be clear, what would you like to happen?

1. Apply fixes for linter issues that can be autofixed
2. Output warning log messages when there are linter violations
3. Raise an error and fail the build when a file has linter violations

(1. sounds goods to me, 2. isn't really useful if you want to use automated tooling, 3. feels wrong to me but I'm open for other opinions)

[jdsee]

For our release builds we want to enforce, that the formatter and linter has been run on changed code. If we want to stick with spotless only, we'd need option 3.

1 isn't really necessary for our purposes, but would surely be a convenient addition.
2 doesn't really make sense, since it's not automatable and too easy to miss.

For reference, the Diktat integration simply fails on linter validations, when running spotless:check.

To make it concrete, ideally we'd need the following:

• a config option, to enable Linting for Biome
• if enabled, sptless:check will fail on linting violations
• if enabled, spotless:apply will fix autofixable linting violations

Thanks for considering!

[blutorange]

I would probably split that into 2 options (failOnLintRuleViolations and applyLintRuleFixes=(safe|unsafe))

Doesn't sound too hard to implement, but since I'm not the maintainer of spotless (I just added the biome formatter), I'd like to wait for @nedtwigg opinion on this.

[jdsee]

Sounds really good to me. Thank you!

[blutorange]

Starting with version 2.0, biome now has rules that require scanning the entire project:

Since Biome v2, we’ve extended its architecture with a tool called Scanner. The Scanner is responsible for crawling your project files and creating important information such as the module graph and the inferred types.

Such information is needed for some rules as noFloatingPromises, noUnresolvedImports or noImportCycles, which can’t function otherwise. Generally, for rules that belong to the project domain

https://biomejs.dev/linter/#why-is-biome-linter-so-slow-compared-to-v1

So I think that means that we can at best only support a subset of rules that don't require this scanning, as spotless always considers files separately from one another.

[lkoe]

I want to have biome run assists as well, particularly organize-imports.
This too, would require to run the check command.

I think that's less contentious than running linting, since other formatters (java, kotlin) do organizing imports as well.

A way to do this would be running check instead of format and explicitly adding --javascript-linter-enabled=false to disable linting.
A new configuration option (biomeCommand, defaulting to format) would work for me as well.

[lkoe]

I created a separate issue (#2801) for the assists-Part and a low-key pull request