Repository navigation
lint,fmt: Deprecate the wrapper bin for stable IDE support #1557
Description
Currently, lint|fmt IDE support for Vite+ is implemented as follows:
- When the
vite-pluspackage is installed locally, the package manager placesbin/oxlint|fmt- These are special binaries with
vite.config.tssupport enabled, distinct from the standardoxlint|fmtbinaries
- These are special binaries with
- Individual editor extensions then reference these binaries and launch
--lsp- The discovery process for these binaries should remain the same as in non-Vite+ projects
However, some issues have also come to light.
- When using
npmoryarnas the package manager, the custom binary is not installed at all!- vite-plus
bins conflict withoxfmtandoxlintbins #1482 pnpmandbunworks
- vite-plus
- Installing
oxlint|fmtseparately overwrites the custom binary- IMO: This should be triaged as a separate issue, since this overrides
vp lint|fmttoo
- IMO: This should be triaged as a separate issue, since this overrides
- When you try to setup editor by yourself, it's unclear to know what should be used
- The priority of the method VSCode extension uses to search the
bin/was lower than that ofrequire.resolve(), causing it to fail to locate the custom binary when other workspaces were open
Proposed solution
Following our team meeting, we would like to proceed as follows.
- Deprecate the wrapper binary
- Editors that support LSP should use
vp lint|fmt --lspinstead - Editors that do not use LSP should use commands like
vp fmt --stdin-filepath
Tasks
- Stop writing
VITE+...header message to stdout for these usecases @fengmk2vp lint --lspvp fmt --lsp,vp fmt --stdin-filepath
- Define a standardized way to determine "whether a project is a Vite+ project or not" @fengmk2
- Update editor extensions to detect Vite+ project and use
vp lint|fmt --lsp- feat: support Vite+ detection and per-tool source selection oxc-project/oxc-vscode#384
- feat: support Vite+ detection and per-tool sources oxc-project/oxc-zed#259
- feat: support Vite+ detection and per-tool sources oxc-project/oxc-intellij-plugin#583
- feat: support Vite+ detection and per-tool source selection oxc-project/coc-oxc#247
- Remove wrapper bin
- Update docs?
Reacted by Max
Reacted by JongKyung Lee , Nicolas Stepien and Alexander Chehovskii
Activity
leaysgur commentedon May 12, 2026
@fengmk2 Are we getting this right?
@Sysix @nrayburn-tech Any thoughts on this?
fengmk2 commentedon May 12, 2026
@leaysgur LGTM 💯
You can directly assign me any tasks that need help.
Sysix commentedon May 12, 2026
Instead of
node node_modules/.bin/oxlint, should we targetnode node_modules/.bin/vp?Running
vpnatively could be tricky on VS Code extension. Currently, there are problems detecting node with some non-standard setups, likemiseandnvm. Running VS Code via CLI or via GUI can change the context too (oxc-project/oxc-vscode#255).leaysgur commentedon May 13, 2026
That is my understanding. So, we need to resolve
nodeandoxlint|fmt|vpseparately, right?EDIT: One more question, what was the motivation to resolve
nodeitself instead of leaving it to shebang in bin?@fengmk2 Please let me know if you have any thoughts on this. Also, it looks like we need to define a standardized way to determine "whether a project is a Vite+ project or not".
nrayburn-tech commentedon May 13, 2026
No major concerns from me.
IntelliJ doesn’t have the same user base as VS Code, so it doesn’t support as many variations as Sysix has to try and figure out.
The Zed extension API is very limited which is always a concern if anything new needs to be introduced, but I don’t think this change should be a problem there.
For your question about whether a project is a Vite+ project or not, what context are you trying to answer that in? The existence of the package in the package.json file tells us that a project is Vite+ (some nuance here with different package managers and transitive dependencies, but nothing special). This isn’t typically an issue to solve at the plugin level, but maybe you’re trying to get that information in a different context so that’s not always helpful.
leaysgur commentedon May 13, 2026
Thank you!
The reason I brought up the Vite+ project detection was due to these questions:
package.jsonin that directory, we don't know if it's the rootpackage.jsonor notpackage.json, what would be considered the "root marker"?require.resolve('vite-plus')or something?If these aren't actually issues, then my concerns were unfounded. 🙈
nrayburn-tech commentedon May 13, 2026
I see. I do think those can be problems, but I assume (big assumption) they’re solved already within the plugins. The same issues exist for Oxfmt/Oxlint that now exists for Vite+. Each plugin could be solving this completely differently though, which could provide a slightly different experience.
fengmk2 commentedon May 13, 2026
@leaysgur Let me think about this question. I will provide a standard solution. I understand that not only the oxc extension needs this logic handling, but Vite+ itself also needs this in it's
migratecommand.leaysgur commentedon May 13, 2026
Thank you, please!
Also, may I ask you to handle
VITE+ ...message fixes? 🙏🏻fengmk2 commentedon May 13, 2026
Sure, I will handle it too.
Sysix commentedon May 13, 2026
Yes. The
oxlint/fmt/vppart is easy. Thenodeorvpwill be difficult. I learned this week that VS Code (electron app) are loading different envs. Maybe something like oxc-project/oxc-vscode#261 will help 🤞Can't remember the right reason, but every platform does handle things differently + the shell problems below:
Little summary from ChatGPT 🤖:
leaysgur commentedon May 13, 2026
Got it, thanks. 🥹
Anyway, I'll let both of you know here once the preliminary tasks (by MK) are complete.
22 remaining items
docs(rfc): expose installed vite-plus version for LSP gating
fengmk2 commentedon May 18, 2026
@Sysix @nrayburn-tech https://github.com/voidzero-dev/vite-plus/pull/1614/changes a standardized way to determine "whether a project is a Vite+ project or not" RFC, please help review and provide any feedback or suggestions. 💌
fix(cli): suppress VITE+ header for lint/fmt LSP and stdin flows (#1619)
docs(rfc): add "Vite+ Project Detection for Editor Extensions"
docs(rfc): correct marker non-targets — .vite-hooks is real, .vp-root…
docs(rfc): expose installed vite-plus version for LSP gating
Stanzilla commentedon May 20, 2026
I'd rather see the project move this direction oxc-project/oxc#22539 to avoid all this extra headache
bins conflict withoxfmtandoxlintbins #1482leaysgur commentedon Sep 17, 2026
@fengmk2 @Sysix @nrayburn-tech
I hesitated to write essentially the same thing across four separate IDE PRs, and since everyone involved is gathered here, I'll leave my comment here instead.
(Resolving this issue is also necessary for the upcoming VP 1.0 release, so I'd really appreciate your help... meaning it would be a huge help if you could review PRs. 🙏🏻 (though of course, after your vacation!))
First of all, in the current PR, nested config support is forcibly disabled on each IDE side, but I'm thinking we should do it collectively for both CLI and LSP on the Oxapps side.
As for the unified behavior in VP mode, it will only use root find-up, which applies to both CLI and LSP usage.
This will also help #2698
NOTE:
.lint|fmtis placed somewhere other than the project root-cin the CLI to align the behaviors of the CLI and LSP is a separate topicPRs for IntelliJ and VSCode partially include changes (with different approaches) to prevent the VP mode LSP and the standard LSP from conflicting.
My understanding is that this only partially resolves the issue previously reported for VSCode as oxc-project/oxc-vscode#145.
(Zed and CoC are structurally unaffected by this issue in the first place.)
While we need to decide whether to introduce the complete implementation at this stage, I think we at least need to reach a consensus on the direction?
In VS Code, features like SaveAll and the Problems panel could still end up running with the wrong LSP, and the intended config files won't even be recognized in the first place.
UPDATE:
node_modules/.bin/oxfmt, which Vite+ 1.0 no longer installs oxc-project/oxc-vscode#401Failed to run oxlint. Click to show error.in Zed Editor oxc-project/oxc-zed#266For these reasons, I am planning to recreate a PR with a minimal scope and merge relatively soon.
fix(cli): remove oxlint and oxfmt bin wrappers (#2672)
feat(oxlint,oxfmt): do not discover nested config in Vite+ mode (#26763)