chore: use biome as formatter and linter

[watany-dev]

While this undoubtedly leads to efficiency gains, it's worth discussing its adoption, as there may be room for debate. However, it's certain that the integration would speed up the workflow.

Author should do the followings, if applicable

• Add tests
• Run tests
• yarn denoify to generate files for Deno

[watany-dev]

Biome 1.4 is out and will be updated after this.

https://biomejs.dev/blog/biome-wins-prettier-challenge

[yusukebe]

@watany-dev

I've never tried Biome yet, so I'll try it.

[yusukebe]

Biome seems to be good! It's fast!

However, in my opinion, it might be too early to introduce it to our project. Many developers have already installed extensions for prettier and eslint, but that's not the case for biome. While the linter and formatter can work on CI, it's better if they also work in the users' local environments. To achieve this, users would need to have the biome extension installed, right?

[watany-dev]

Thanks for checking!
You may be right in that sense. We can preset it to Devcontainer, for example, but the local environment of the developer is not limited to that. we'll think about it again when we have enough to change the share of formatter and linter.

[yusukebe]

Okay!

[CarlosZiegler]

Hello,
I like this discussion, I aggred what @yusukebe said but user will be add the extensions for prettier and eslint too or ? I am using biome in two projects, and for me is easy to manage both, only install biome, and enable extensions, dont need to care about conflict of my eslint and project eslint or something like that.
Another thing is the rules, of my side I think cover better as es-lint:
Link: https://biomejs.dev/linter/rules

• Accessibility : Rules focused on preventing accessibility problems.
• Complexity : Rules that focus on inspecting complex code that could be simplified.
• Correctness : Rules that detect code that is guaranteed to be incorrect or useless.
• Performance : Rules catching ways your code could be written to run faster, or generally be more efficient.
• Security : Rules that detect potential security flaws.
• Style : Rules enforcing a consistent and idiomatic way of writing your code.
• Suspicious : Rules that detect code that is likely to be incorrect or useless.
• Nursery : New rules that are still under development.