Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Support external `vp-<command>` executables, as Git and Cargo do

Closed
  • Is something wrong?
#3,195 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@cpojer is already working on this.

Since Oct 22, 2026.

Assessment

This issue has not been assessed yet.

Description

enhancement pending triage

Problem

Workspace tool authors cannot expose a command such as vp pr gen: the global
CLI rejects pr before the workspace's JavaScript implementation can run.
Today our workspace runs the same tool with vp exec vpp pr gen.

Reproduction

With an executable named vp-pr installed in the workspace's node_modules/.bin,
vp pr --help should be able to run that executable with --help. With Vite+
1.3.0 installed, the current command exits 2 with error: Command 'pr' not found.
Patching the local dist/bin.js dispatcher does not help: it is never reached.

Checked source

Inspected the official repository at commit
733b973ebe26f097ebe007cb079b2ee64b2f7217 in ~/repo-references/vite-plus:

  • main.rs:522
    calls try_parse_args_from before command execution.
  • main.rs:537
    handles InvalidSubcommand as an error/suggestion. Only the successful parse
    arm reaches run_command at line 583.
  • cli.rs:69
    declares the closed Commands enum. It has no external-subcommand arm.
  • cli.rs:1298
    calls clap's try_get_matches_from and Args::from_arg_matches.
  • cli.rs:1179
    already routes exec through the managed local executable path.

Proposal

Support Git/Cargo-style external subcommands: when no built-in matches foo,
resolve vp-foo using the same managed runtime and workspace executable
resolution as vp exec, then forward the remaining argv unchanged.

Built-ins retain precedence. Unknown names still fail with the existing useful
error when no executable exists. No implicit package download or install is
needed. Preserve cwd, -C, stdout/stderr, exit status, signals, --, and platform
executable/shim behavior. A locally installed extension should be explicitly
available in the workspace, not inferred from a matching package name.

This gives workspace extensions a natural command without modifying Vite+'s
built-in command set or maintaining an unreachable JavaScript dispatch patch.

Suggested acceptance cases

  • vp foo a --flag -- value executes vp-foo with exact argument boundaries.
  • Existing built-ins win over a same-name executable.
  • Workspace executable resolution and -C behave like vp exec.
  • Missing executable retains the unknown-command error; no download occurs.
  • Child exit code and termination signals propagate.
  • Unix executables and Windows executable shims both work.
Dominant language
Rust
Stars
6.3k
Forks
283
Avg merge
1d 12h
Merged PRs (30d)
235

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from voidzero-dev/vite-plus

All issues in voidzero-dev/vite-plus

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.