Conversation
|
I don't think this is a good idea. There might be users that want and accepts warnings in their code. |
I don't really see the use-case for running Furthermore, the default pre-commit handlers for other linters defaults to failing when there is an unfixed lint. If the user really wants to have warnings in their code then I don't think pre-commit is the right tool, as the warnings won't even be shown. However, if there is some weird use-case, they can override the entrypoint in their pre-commit config. |
|
Still, Biome emits warnings that sometimes fall outside the linter's ecosphere, meaning users can't control them directly until they are fixed. This means that every time we decide to emit a warning, this will fail. For example, we recently landed an update where we emit a internal diagnostic, a warning one, which isn't easily fixable. This could cause a DX friction to the tool. As you said, users can customise the entrypoint, so for now you can do that too, until we (the team) decides how we should handle our internal diagnostics. |
Fair enough. Is there another flag for only exiting with a non-zero exit code when there are lints? |
|
I always run the pre-commit hook with |
Fixes #58