fix(oxlint,oxfmt): Check env.VITE_PLUS_VERSION for Vite+

[leaysgur]

Fixes #20416

• Both: Update test utils to accept env vars
• Oxlint: Also disable nested config for Vite+

Vite+ PR: voidzero-dev/vite-plus#946
(We don't need to worry about the release timing, since Vite+ locks our version.)

[leaysgur]

• fix(oxlint,oxfmt): Check env.VITE_PLUS_VERSION for Vite+ #20417 👈 (View in Graphite)
• fix(oxlint,oxfmt): Redirect JS stdout to stderr for LSP #20321 : 1 other dependent PR (#20327 )
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent changes, fast-track this PR to the front of the merge queue

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[camc314]

Can you explain how this works with LSP?

I think users have to manually configure the env var? This will break support when users are using 1x VP workspace & 1x non-VP workspace, since env vars are singletons across the process. Futhermore, I think this increases the barrier to entry, in the same way that requireing a CLI flag to work out which config file would be.

[leaysgur]

I think users have to manually configure the env var?

This is false, since Vite+'s bin wrapper handle this.

https://github.com/voidzero-dev/vite-plus/pull/946/changes

---

This will break support when users are using 1x VP workspace & 1x non-VP workspace, since env vars are singletons across the process.

This is yes, and no.

But this may be a trade-off... Do we break Oxc users to support Vite+, or do we protect one and break the other?

Personally, I think this approach is safer, as long as it works if the relationship between the workspace and the LSP is properly maintained. At least for now, this will only affect Vite+ users, whereas before, both Oxc and Vite+ users were having issues.

But if we do oxc-project/oxc-vscode#145, this plan will work without worries.

[Sysix]

But if we do oxc-project/oxc-vscode#145, this plan will work without worries.

This only will "fix integration" with VS Code.
Copying from oxc-project/oxc-vscode#145 (comment)

We should also be careful about other IDEs and how they integrate with LSP and our server. "Fixing" it on the IDE side will force us to test one more scenario how oxlint --lsp and oxfmt --lsp interact with an editor. Would love to see a consistent across the editors 🫶

I added a notice in the issue, that the "root" problem could also affect non js/ts config.

[leaysgur]

In the current situation,

• merely touching vite.config.ts causes an error
• And to load vite.config.ts without error in most cases, a vite implementation is essential
• However, it is unlikely that Oxapps will add vite as dependency

Given this premise, I believe the only thing Oxapps can do is to make it possible to completely ignore vite.config.ts via a switch.

In that case, enabling the Vite+ mode switch becomes a responsibility of the extension, and I believe that is a necessary cost for the feature of supporting Vite+.