Biome vs. Oxlint: should biome use typescript go?

[ziimakc]

I've read this article: https://www.solberg.is/fast-type-aware-linting and curious on your opinion about:

My conclusion: Oxlint is making the right long-term bet.
By aligning with tsgo, they inherit every future optimisation the TypeScript team ships, while keeping the rule surface identical to typescript-eslint. Once tsgolint graduates from experimental to stable, Oxlint will wrap it and ship the full 40-rule suite in one release—no gradual catch-up, no behavioural drift. That is the moment we will drop the hybrid setup and run a single, blazing-fast linter that already understands our codebase.

I like biome and wish it stay ahead of competitors.

[arendjr]

I don't think we need to see it as an either-or situation. Once tsgo integrations work well, we can integrate it into Biome too, and our users can have the choice which approach they prefer. But I'm actually happy that Oxlint is doing the hard work on that front :) For us to support it as an additional backend is far less work when they've already built the Rust <-> tsgo interop.

I very much believe in our own inference effort, but I also understand there will be users for whom 100% compatibility with official TypeScript may be more important, so I would be happy to offer both.

[rahdirigs]

Are there any plans to revisit this? As per recent data, oxlint supports 59 out of their targeted 61 rules from typescript-eslint through tsgolint.
We are planning to migrate our monorepo away from eslint, and evaluating between our choices (oxlint + oxfmt and biome) at the moment. We generally prefer biome's approach to monorepos over oxlint, but lack of compatibility with typescript is really a kicker at the moment.

[rahdirigs]

I have already been through the resource you have linked, but found a lot of the no-unsafe-* and no-useless-* family of rules aren't implemented. Even the ones implemented like useAwaitThenable and noFloatingPromises are still in nursery, with useAwaitThenable having a caveat (as highlighted in the rule documentation) compared to the corresponding eslint implementation, which I suppose is a drawback of having a custom type inference system? Would I be wrong in assuming that had Biome's underlying type inference system leveraged tsgo (I understand that integrating it might be hard) for the type information and semantic analysis, we could have possibly had full compatibility with typescript / typescript-eslint?

[Netail]

You can see all rules that we've implemented so far from typescript-eslint at https://netail.dev/are-we-biome-yet/ :)

66 out of 127 (52%)

[rahdirigs]

@Netail I don't mean to any way, or form intend to undermine the efforts being put into this project. If anything I am super appreciative of what you guys do, and this is the goto tool for my personal projects (Ultracite introduced me to this about a year ago, and since then I have gone onto maintain my own configs).
And as such when it was decided at work that we want to try and move away from eslint (due to CI times), we are considering biome as an alternative (along with oxlint). That said our current eslint configs have most of the rules requiring type information turned on, and based on the tracker shared, what I see is most of the red tiles are rules requiring type information (this was known to me prior to my initial post on this).
So my initial thoughts were if Biome's dependency on its own type inference engine, was slowing down progress when it comes to these specific rules (given that almost all rules from this category that have been implemented are still in nursery, and one of them useAwaitThenable has an open disclaimer that the behaviour is not a 1-to-1 replica of what typescript eslint provides).
As for why I brought this up now? The original response from the core team member was that they would happy to support this once tsgo interop was possible. And during my digging I found that tsgolint has almost achieved feature parity in this area (tsgolint implements 59/61 rules requiring type information). Hence the ask of whether this is in the plans, in which case my team would be ok with migrating over and enable more rules as and when they ship. But if its a given that we have to live with the caveats (nursery classification + lack of 100% compatibility with ts-eslint), unfortunately we might have to look elsewhere for now.

[Netail]

Almost all rules from typescript-eslint require type information. Most of the red tiles are yet to be implemented as they need to be ported to rust (PRs are welcome :)), but haven't been done yet

[ematipico]

Hence the ask of whether this is in the plans

We are evaluating what the cost and efforts of such a move are; however, that doesn't mean that our inference will go away. Using tsgolint as a backend comes with costs and changes to our architecture. This isn't an easy move, and neither something we can do in one day.

Plus, there's a cost to the community (end users), as Biome introduces a non-trivial external dependency. So if there's a bug, how do we fix it? Who fixes it? There are many factors at play, and it isn't something we can decide in one day. Contrary to oxc, we want to try to own the pipeline as much as we can, so we can fix things swiftly without waiting for upstream dependencies.

Still, yes, we are evaluating and there are team members who are looking into it. Hopefully this answers your question.