chore: setup oxfmt for formatting

[Copilot]

Description

Replaces Prettier with oxfmt (Oxc formatter) based on oxfmt alpha release and previous attempt #945.

Changes:

• Added oxfmt@^0.23.0 as dev dependency, removed prettier
• Created .oxfmtrc.json with settings matching previous Prettier config:
  • semi: false, singleQuote: true, printWidth: 80
  • experimentalSortImports with partitionByNewline: true and groups: [["builtin"], ["external"]] for import ordering
• Updated format script: prettier --write --cache . → oxfmt
• Updated lint-staged to use oxfmt for JS/TS/JSON files (with explicit extensions instead of *)
• Removed eslint import-x/order and sort-imports rules since oxfmt handles import ordering now
• Formatted all files with new formatter

Original prompt

setup oxfmt based on https://oxc.rs/blog/2025-12-01-oxfmt-alpha.html and past attempt #945

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[ArnaudBarre]

Import sorting is way better, but still a lot of diff that could be avoided by keeping node builtins first

[ArnaudBarre]

I'm not a fan of having all type import before runtime ones, it create more diffing when switching from type import to runtime or the other way around and when importing both types and import (I personally like them to be merged) it's cleaner to have them next to each other IMO if not merged

[Dunqing]

Maybe @leaysgur can help set up import sorting properly

[ghiscoding]

Maybe @leaysgur can help set up import sorting properly

I think what you guys are looking for is basically what I asked in this last comment of the same issue you referenced
oxc-project/oxc#14253 (comment)

and for that you should just add this group to your config, which first sorts (1) node:xyz, (2) then external, (3) then internal imports. The "builtin" is for NodeJS imports
"groups": ["builtin", "external"]

I'm not sure if this will ever be the default in the future (I think not), but for now the group needs be to added separately and that is what I started to use in Lerna-Lite and it's pretty much equivalent to what the plugin @ianvs/prettier-plugin-sort-imports was outputting (which is what I used before switching to oxfmt, but now it's 10x time faster 🚀)

Also please note that you should make sure to use v0.16.0 or higher since there was a fix, that was released in v0.16, for internal import detection with @/ and not @ (monorepo) in this PR oxc-project/oxc#16128

[hi-ogawa]

It turned out we use glob overrides for json5 and yaml, but it's not supported yet oxc-project/oxc#17585 (Vite repo also has the same setup https://github.com/vitejs/vite/).

Does anyone know the rational behind this? For json5, I see unquoted { $schema: ... }, which looks scary but seem valid. For yaml, is it also preference (or reducing diff during initial prettier setup)? Personally, I'd prefer simplifying config as much as possible, so I'll put this PR ready for review.

vite-plugin-react/.prettierrc.json

Lines 1 to 19 in 3b87f5a

	{
	"semi": false,
	"singleQuote": true,
	"overrides": [
	{
	"files": ["*.json5"],
	"options": {
	"singleQuote": false,
	"quoteProps": "preserve"
	}
	},
	{
	"files": ["*.yml"],
	"options": {
	"singleQuote": false
	}
	}
	]
	}

[leaysgur]

This is not a fundamental solution, but I'll share what I researched previously.

---

Regarding .json5, both here and vite repository only contain a single file: renovate.json5.

Furthermore, the renovate docs doesn't seem to recommend using .json5 files, so how about changing the file extension?

https://docs.renovatebot.com/configuration-options/

---

Regarding .yml, both repositories already contain a mix of .yml and .yaml files.

Therefore, since the format is inconsistent, there may be little point in deliberately overwriting only .yml files.

(And fundamentally, YAML is a syntax that rarely requires quotes in most cases.)

[sapphi-red]

I think it was a preference: vitejs/vite#4132 (comment)

I guess the main reason of using json5 was to write comments in it. It seems renovate allows comments in .json so that won't be a blocker. I prefer to have trailing commas where possible (renovate doesn't seem to allow them in .json renovatebot/renovate#40330), but I'm fine without it.

Regarding the yaml override, I think there's little downside of removing it.