lint,fmt: Deprecate the wrapper bin for stable IDE support

[leaysgur]

Currently, lint|fmt IDE support for Vite+ is implemented as follows:

• When the vite-plus package is installed locally, the package manager places bin/oxlint|fmt
  • These are special binaries with vite.config.ts support enabled, distinct from the standard oxlint|fmt binaries
• 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 npm or yarn as the package manager, the custom binary is not installed at all!
  • vite-plus bins conflict with oxfmt and oxlint bins #1482
  • pnpm and bun works
• Installing oxlint|fmt separately overwrites the custom binary
  • IMO: This should be triaged as a separate issue, since this overrides vp lint|fmt too
• When you try to setup editor by yourself, it's unclear to know what should be used
  • lint,fmt: Non LSP aware editor support #979
• The priority of the method VSCode extension uses to search the bin/ was lower than that of require.resolve(), causing it to fail to locate the custom binary when other workspaces were open
  • Fixed by: fix(vite-plus): search for node_modules/.bin before resolving to native package oxc-project/oxc-vscode#223

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 --lsp instead
• 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 @fengmk2
  • vp lint --lsp
  • vp fmt --lsp, vp fmt --stdin-filepath
• Define a standardized way to determine "whether a project is a Vite+ project or not" @fengmk2
  • docs(rfc): Vite+ Project Detection for Editor Extensions #1614
• 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
  • fix(cli): remove oxlint and oxfmt bin wrappers #2672
• Update docs?

[leaysgur]

@fengmk2 Are we getting this right?

@Sysix @nrayburn-tech Any thoughts on this?

[fengmk2]

@leaysgur LGTM 💯

You can directly assign me any tasks that need help.

[Sysix]

Editors that support LSP should use vp lint|fmt --lsp instead

Instead of node node_modules/.bin/oxlint, should we target node node_modules/.bin/vp?

Running vp natively could be tricky on VS Code extension. Currently, there are problems detecting node with some non-standard setups, like mise and nvm. Running VS Code via CLI or via GUI can change the context too (oxc-project/oxc-vscode#255).

[leaysgur]

Instead of node node_modules/.bin/oxlint, should we target node node_modules/.bin/vp?

That is my understanding. So, we need to resolve node and oxlint|fmt|vp separately, right?

EDIT: One more question, what was the motivation to resolve node itself 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]

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]

Thank you!

The reason I brought up the Vite+ project detection was due to these questions:

• It's up to the user to decide which directory in a repo as the LSP workspace, indeterminate
• Even if there is a package.json in that directory, we don't know if it's the root package.json or not
• Even if we search-up for a package.json, what would be considered the "root marker"?
• Or require.resolve('vite-plus') or something?

If these aren't actually issues, then my concerns were unfounded. 🙈

[nrayburn-tech]

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]

It looks like we need to define a standardized way to determine "whether a project is a Vite+ project or not"

@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 migrate command.

[leaysgur]

Thank you, please!
Also, may I ask you to handle VITE+ ... message fixes? 🙏🏻

[fengmk2]

Thank you, please! Also, may I ask you to handle VITE+ ... message fixes? 🙏🏻

Sure, I will handle it too.

[Sysix]

That is my understanding. So, we need to resolve node and oxlint|fmt|vp separately, right?

Yes. The oxlint/fmt/vp part is easy. The node or vp will 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 🤞

EDIT: One more question, what was the motivation to resolve node itself instead of leaving it to shebang in bin?

Can't remember the right reason, but every platform does handle things differently + the shell problems below:

Little summary from ChatGPT 🤖:

A few historical accidents stacked together:

• terminals existed before GUIs
• remote logins existed before desktop sessions
• shells were originally for humans, not app environments
• every shell added its own startup semantics
• distros and OS vendors patched behavior differently
• developer tools started abusing shell init files as plugin systems

So now:

• GUI apps inherit one environment
• terminals synthesize another
• shells mutate state dynamically
• toolchains inject themselves into startup scripts
• Electron apps sit awkwardly between desktop app and terminal app

[leaysgur]

Got it, thanks. 🥹

Anyway, I'll let both of you know here once the preliminary tasks (by MK) are complete.