feat(create-vite): eslint -> oxlint

[ArnaudBarre]

The React compiler is probably good engineering but the cost is still to high for me and so I think for a starter template.

Given that:

• The latest version of eslint-plugin-react-hooks has questionnable dependency management that pulls multiple parsers and duplicate dependencies with the babel plugin (they are bundled for Babel, externalized for ESLint)
• ESLint was added in the first place so that the two initial rules of the plugin (exhaustive-deps, rules-of-hooks) are present in the template
• oxlint implemented those two rules
• You need 4 dependency to get started with eslint+typescript

I think it's time to use oxlint in our templates

I'm trying to be as close as possibles to defaults but:

• rules-of-hooks is not in correctness, I think we could rediscussed with the oxc team
• jsx-no-target-blank is enabled by default and goes against our choice here. I asked the oxc team if this can be removed from defaults
• only-export-components, which ports eslint-plugin-react-refresh and validates HMR compatibility is enabled

[Boshen]

rules-of-hooks is oxc-project/oxc#7691, I think we could rediscussed with the oxc team

My comment on PR:

Although this rule is recommended by the React team,
it does not report incorrect or wrong code for the correctness category.

When turned on by default, I find false positive warnings confusing,
I cannot tell whether my code is wrong or the rule implementation is
wrong - see examples in the affine repo.

We can enable it by default if we can generate proper help messages for false positives, otherwise configure it explicitly in the config in the starter template is actually better (I think).

[Boshen]

There is another "problem" that should be noted: https://oxc.rs/docs/guide/usage/linter/versioning.html#versioning

What's considered a non-breaking change:

• Adding new lint rules.
• Changing the default configuration for a rule.
• Improving rule descriptions or diagnostic messages.

Upgrading Oxlint will sometimes break your build, because new rules can be added to the correctness category to surface more errors.

This is similar to upgrading TypeScript.

[bluwy]

I feel it is still early to introduce oxlint. At least once its eslint plugin compat is stabilised, we could start to use it in the templates.

For me it's important to stick to a tool that has a good ecosystem and external resource so we don't alienate users who aren't familiar with js linting. If someone wants to extend the linting config and easily hits hurdles, I don't think it's good DX.

For the dependency issue in the react plugin, if the react team doesn't help with them, then I don't think there's much else we can do other than just upgrading it. There's not much we can do if they recommend a chonky setup as a bare minimum.

[sapphi-red]

I agree with bluwy.

One thing we might be able to do is to ensure oxlint-migrate can migrate our config and recommend running that for users if they prefer.