Differences between oxlint and biome?

[mcmxcdev]

I am following along the progress of oxlint and rome/biome for a while now and would like to understand why both tools, which are so similiar in philosopy are being developed as separate standalone tools.

According to https://npmtrends.com/@biomejs/biome-vs-oxlint, biome has 91k downloads per week while oxlint has 25k downloads per week, both tools are built in Rust, reimplement various ESLint rules and are probably encountering similar bugs and problems too.

I think it would be great to combine biome and oxlint into one, leading to higher velocity, more developer activity and less ecosystem fragmentation where devs have to get informed about both and pick one over the other for reason x or y.

[Boshen]

Give both a try and see which one fits your requirements. Biomes excel in every aspect at the moment.

[alexleduc76]

The ESlint formatting rules have just been moved to an ESlint plugin, not deprecated. If OXC doesn't plan to implement those, then I guess I'll just keep using ESLint until someone makes a Rust port of it or something.

Edit: Never mind, you are right about the word "deprecated". Still, I'm glad the functionality is still there, even if it's spun off as a plug-in.
https://eslint.org/blog/2023/10/deprecating-formatting-rules/

[alexleduc76]

Maybe the tool I'm looking for doesn't exist. Something that would solve this would be a "meta formatter" editor plug-in, that applies its own in-RAM-only representation of the code and on-the-fly converts the code in the format you prefer in your editor, but when you save the file, it separately runs the code through an opinionated formatter and that is what is saved to disk. This way, stylistic formatting rules would not affect Git commits(*), and people who hate the imposed opinionated formatting would have their cake and eat it. *(talking about the annoying thing where someone overtake the git blame on every line of code changed by having different formatting rules than everyone else).

[iwt-nduesing]

@alexleduc76 I think you missed the advantage of prettier. In your article you bring the case whether else is in a separate line or not. For readability it doesn't really matter. Your argument is, that you are used to your way, so you want to keep it, which is fair. But if someone new joins you team they are maybe irritated by it. And as it's an option, you could format it differently. So you have a discussion with them. I spend hours in the past with colleagues discussion about how we want to format the code. Time that is wasted. What prettier achieved is to stop discussions. The whole world kind of just uses prettier now. So people don't choose prettier because they agree with their formatting, but because they don't have to think nor discuss about the formatting rules.

[alexleduc76]

@iwt-nduesing I would just shut down the discussion if anyone tried to challenge the formatting rules. The lead developer should make these decisions, and they should not be up for debate.

I have not missed the argument that Prettier's imposed formatting stops such discussions, but I disagree that it does. Someone could disagree just as much with the Prettier imposed formatting than the one I impose with ESLint rules, and argue that we should use another tool than Prettier for that reason. Prettier is not what shuts down formatting debates, it's the responsibility of the person with the authority to make those decisions.

[iwt-nduesing]

@alexleduc76 well, not everyone works in a top down hierarchy organization. This is the first time for years I see someone arguing for using a different tool than prettier for formatting, because they don't like their rules.