chore: set up vite+

[TheAlexLichter]

Description

Only take a look at the latest commit. Stacked on #1120 (cant stack across PRs)

This PR moves from Oxlint and Oxfmt to Vite+ as a PoC. I know this will need some discussion around it but happy to chat 😋

Validation

Run all commands and see CI

Related Issues

Check List

• I have read the Contributing Guidelines and made commit messages that follow the guideline.
• I have run node --run test and all tests passed.
• I have check code formatting with node --run format:check & node --run lint.
• I've covered new added functionality with unit tests if necessary.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
api-docs-tooling	Ready	Preview	Oct 5, 2026 8:17am UTC

[codecov]

Codecov Report

❌ Patch coverage is 99.65636% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 92.72%. Comparing base (3b3a4e9) to head (6769278).

Files with missing lines	Patch %	Lines
scripts/update-type-map.mjs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1121      +/-   ##
==========================================
+ Coverage   92.64%   92.72%   +0.08%     
==========================================
  Files         244      245       +1     
  Lines       23114    23390     +276     
  Branches     2263     2263              
==========================================
+ Hits        21413    21689     +276     
  Misses       1692     1692              
  Partials        9        9              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

api-links Generator

Performance estimate _{(single CI run)}

• Generation time: 62.4% slower (930.00 ms → 1.51 s)
• Peak memory: 3.7% lower (440.48 MB → 424.05 MB)

json Generator

Performance estimate _{(single CI run)}

• Generation time: 49.9% slower (6.90 s → 10.34 s)
• Peak memory: 8.0% lower (1.58 GB → 1.46 GB)

legacy-html Generator

Performance estimate _{(single CI run)}

• Generation time: 11.4% slower (41.47 s → 46.19 s)
• Peak memory: 1.4% lower (2.41 GB → 2.38 GB)

legacy-json Generator

Performance estimate _{(single CI run)}

• Generation time: 10.8% slower (8.71 s → 9.65 s)
• Peak memory: 1.0% higher (1.56 GB → 1.57 GB)

llms-txt Generator

Performance estimate _{(single CI run)}

• Generation time: 36.1% slower (4.93 s → 6.71 s)
• Peak memory: 9.4% lower (1.83 GB → 1.66 GB)

orama-db Generator

Output size: 1 file changed · net -141.00 B

File size details

File	Main	PR	Change
orama-db.json	9.54 MB	9.54 MB	-141.00 B (-0.0%)

Performance estimate _{(single CI run)}

• Generation time: 47.5% slower (4.99 s → 7.36 s)
• Peak memory: 3.5% higher (1.84 GB → 1.90 GB)

web Generator

Performance estimate _{(single CI run)}

• Generation time: 32.4% faster (64.65 s → 43.72 s)
• Peak memory: 20.7% higher (3.33 GB → 4.02 GB)

[ovflowd]

SGTM! Although, @TheAlexLichter the PR needs a rebase!

[MattIPv4]

My initial reaction to this is: why?

Why do we need to keep switching tooling every month to chase the new hotness? Why can't we stick with stable and time-proven tooling used by the industry writ large? And why do we keep introducing tooling that is different from our other projects?

I don't mean to come across as overly negative and I'm sure there are some performance gains from this, but this just strikes me as an unnecessary change that creates yet more mental overhead working with this project alongside our others.

And, honestly, it feels weird that it is folks from Vite+ themselves opening this PR to push their new tooling upon us.

Until we've got clear consensus on this value add here and alignment, I'm going to block this for now.

[TheAlexLichter]

Hey @MattIPv4 👋

before jumping into your points, some additional context in the main PR.

Why do we need to keep switching tooling every month to chase the new hotness? Why can't we stick with stable and time-proven tooling used by the industry writ large? And why do we keep introducing tooling that is different from our other projects?
I don't mean to come across as overly negative and I'm sure there are some performance gains from this, but this just strikes me as an unnecessary change that creates yet more mental overhead working with this project alongside our others.

IMO @bmuenzenmeyer summarized it nicely in this comment to be a bound experiment with intent rather than "yet another change":

There are benefits in terms of number of packages, convenience, and speed (all while keeping things interoperable).

And, honestly, it feels weird that it is folks from Vite+ themselves opening this PR to push their new tooling upon us.

I, in no way, want to "push tooling upon you". This came up as a discussion first and sometimes showing is the easiest. I made these (and previous) PRs being aware that they could've been closed with a "no thank you". Sorry if it came across that way!

[MattIPv4]

Ah, I had missed that original PR and the context there, thanks. The review request on this PR was the first I had heard about any of this change.

Again, don't want to be perpetually negative and I'm not against an experiment, and agree that of all the repos we own, this is probably the best to do it in.

Though, I'm not sure this repo alone is really representative of the scope/size of our projects and I'm not sure would be enough for me to then agree we should adopt this tooling everywhere else.

The gains outlined in the original PR were a ~2s saving and ~100 transitive dependencies. I personally am not sure I see that as super strong reason to chase the latest tooling rather than sticking with what we know is widely adopted and stable?

Has any analysis/experimentation been done on our other projects, to indicate we might see more substantial gains in those, that'd then make this a worthwhile change to our tooling consistent across all our projects? I'd quite like to see a case for this being a value add as a whole before we land changes.