oxc VS typescript-eslint

If I understand it right, we have 3 large projects that aim to replace most of JS tools on their own: Bun[0], Oxc[1] and Biome[2]. Bun's package manager is great, Biome formatter recently reached 96% compatibility with Prettier, and now Oxlint is apparently good enough to replace ESLint at Shopify. Exciting times ahead.

But it's giving the impression that these projects perhaps could be better off collaborating instead of each of them aiming to eat the world on their own?

[0] https://bun.sh/

[1] https://oxc-project.github.io/

[2] https://biomejs.dev/

Email: [email protected]

Hi, I'm u9g. I'm looking for an internship for either this winter (in a few weeks) or a summer internship!

Some things I've done:

I integrated a [query engine for lints](https://github.com/obi1kenobi/trustfall) (and contributed optimizations) into [OXC](https://github.com/oxc-project/oxc) (a new Rust-based Javascript Linter).

I wrote [several](https://github.com/u9g/money-lens) [toy](https://github.com/u9g/quickquestion/tree/main/extension) languages and syntax highlighting for them.

I also wrote a [js-to-scheme transpiler](https://github.com/u9g/js2scheme/blob/main/example.js).

Happy to work on things compiler or database oriented, but also happy to learn something new!

Oxc (The Oxidation Compiler)

Typescript-eslint can assist in this task. This tool helps identify all instances of unsafe any usage. Specifically, all usages of JSON.parse can be found and it can be ensured that the received data's format is checked. More about getting rid of the any type in a codebase can be read in the article Making TypeScript Truly "Strongly Typed".

> Only lint files that have changed? How hard that is?

Quite hard, especially since type-aware rules from e.g. https://typescript-eslint.io/ mean that changing the type of a variable in file A can break your code in file B, even if file B hasn't changed.

The article only touches this: when converting to TypeScript, `any` is useful, but in the end you don't want this type in your codebase - so don't forget to use typescript-eslint [0] and turn on those no-unsafe-* rules which guard against `any` leaking into your code.

[0] https://github.com/typescript-eslint/typescript-eslint

By convention, React components should be named in PascalCase. @typescript-eslint has the config we need, and though we can't specifically target React components, we can target variables (and set some other conventions while we're at it):