Exec in place instead of spawning and waiting in the CLI's wrapper processes
Los mantenedores suelen responder en 1 día
@fengmk2 ya está trabajando en esto.
Desde el 18/10/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
Follow-up to #2936, which made the project-local vpx bin replace itself with the script's Node.js through process.execve() on Unix instead of spawning it and waiting. The global CLI's shims already exec in place (exec_tool in crates/vp_global_cli/src/shim/exec.rs). Several other paths still spawn a child only to wait for it and pass its exit status on.
Why
- One PID and real signals. The wrappers ignore SIGINT so that Ctrl+C reaches the child through the process group, and none of them forwards SIGTERM or SIGHUP. A tool that holds the PID of
vpand sends it a signal (kill <pid>, a process manager, a test harness) stops the wrapper, or nothing, while the real process keeps running.SIGUSR1opens a Node.js wrapper's inspector instead of the tool's, and kills the Rustvpwrapper while the tool keeps running. - Exact exit status. A child killed by a signal comes back as a plain exit code (
exit_code_from_status,exit_status_from,process.exit(n)inbin.ts), so callers cannot tellSIGINTfromexit 130. - Fewer idle processes.
vp devthrough the global CLI runs three processes:vp(Rust) waits fornode dist/bin.js, which waits for the Vite Node.js process. An idle Node.js wrapper holds about 50 MB for as long as the dev server runs.
Startup time does not change, since each wrapper still starts before it execs.
Candidates
Strongest first. "After the child" is what the parent still does once the child exits, which an exec must move earlier or keep on the spawn path.
| # | Command | Where | After the child |
|---|---|---|---|
| 1 | global vpr → node <vite-plus>/dist/bin.js run … |
js_executor.rs run_js_entry → vp_command::execute_with_terminal_guard |
nothing (shim mode skips the upgrade notice) |
| 2 | global vpx pkg@version / -p / -c → package manager dlx |
vpx.rs → vp_pm_cli resolution/runner.rs run_command → vp_command::run_command |
nothing |
| 3 | vp env exec --node <v> [--npm <v>] <command> |
commands/env/exec.rs:235-252 |
the upgrade notice; the shim branch of the same command already execs |
| 4 | vp sync-versions with the packaged sidecar |
commands/sync_versions.rs:32-35 |
nothing |
| 5 | vp exec <command> for one package, without --report-summary |
binding/src/exec/workspace.rs:254 |
nothing in that case |
| 6 | vp dev, preview, build, test, pack, doc, lint (not --init) |
binding/src/cli/execution.rs:36-57 |
nothing; the --init and fmt paths filter output and stay as they are |
| 7 | package-manager passthrough in the local CLI (vp install, add, dlx, …, and the local vpx pkg@version) |
binding/src/cli/mod.rs → vp_pm_cli runner |
the toolchain hint after vp why only |
| 8 | global CLI delegation to JS (vp dev, build, test, lint, fmt, check, pack, run, …) |
cli.rs → commands/delegate.rs → js_executor.rs |
the cached upgrade notice (main.rs:597-599) |
| 9 | global package-manager passthrough (vp install, add, why, …) |
cli.rs → vp_pm_cli runner |
the vp why hint and the upgrade notice |
Rows 2, 7, and 9 share vp_pm_cli's runner and vp_command::run_command, so an exec variant there covers them together. Rows 5–7 run inside the Node.js process of the local CLI. For row 8, the upgrade notice has to print before the exec, keep the spawn path when a notice is due, or be dropped as the shim branch already does.
Not candidates: npm install -g / uninstall -g (they link bins afterwards), vp fmt and vp check (they filter or capture output), vp run / vp cache (task graph, many children), multi-package and --parallel vp exec, the installer (it owns the temp directory with the binary), and every call that captures output.
Lessons from #2936
- Blocking stdio. Node.js sets
O_NONBLOCKon a pipe once it opens it as stdio, andprocess.execve()passes that on (nodejs/node#66824), so the new program's writes fail withEAGAIN.bin.tsalready restores blocking stdio; anything that execs from Node.js must do so first. - Signal dispositions. Node.js ignores SIGPIPE and SIGXFSZ, and an ignored signal stays ignored across exec. std's
CommandExt::execrestores SIGPIPE but not SIGXFSZ.vpx-bin.tsrestores both by adding and removing a listener. - A failed exec.
process.execve()aborts Node.js on failure before 26.12 instead of throwing.vpx-bin.tsexecs binaries through/bin/sh -c 'exec "$0" "$@"'for that reason. A Rust exec returns an error the caller can still report. - IPC. Exec closes an IPC channel, so a process started with one (
NODE_CHANNEL_FD,process.send) keeps spawning. - Windows has no exec, so every path keeps its spawn there.
- Rust side.
tokio::process::Command::as_std_mut().exec()keeps the configured env, cwd, andpre_exechooks (such asfix_stdio_streams), so the existing command builders can be reused.
Suggested order
- Add a Unix exec variant to
vp_commandnext torun_commandandexecute_with_terminal_guard, and use it for rows 1–4. - Use it for the local CLI's paths (rows 5–7), skipping exec when the process has an IPC channel and restoring SIGXFSZ.
- Decide the upgrade notice, then switch rows 8 and 9.
Separately, vp run does not forward SIGTERM to its tasks, which is out of scope here because it manages many children.
- Lenguaje dominante
- Rust
- Estrellas
- 6.3k
- Forks
- 283
- Merge medio
- 1 d 14 h
- PR fusionados (30 d)
- 231
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de voidzero-dev/vite-plus
-
pending triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
voidzero-dev/vite-plus#2882 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
voidzero-dev/vite-plus#2097 · 10 comentarios · 2 reacciones ·
Los mantenedores suelen responder en 1 día
-
`pnpm create vite-plus` and `yarn create vite-plus` fail with `spawn vp ENOENT` when `vp` is not on PATHPosiblemente ocupada @fengmk2 la tomó hoy. Abiertobug
voidzero-dev/vite-plus#3177 · 1 reacción · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
vp migrate doesn't flag esbuild-specific config (minify: "esbuild") — migrated project fails to build on Vite 8Posiblemente ocupada @john-okeefe la tomó hoy. Abiertocontribution welcome
voidzero-dev/vite-plus#3176 · 1 reacción · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
`vp run`: scripts get a non-blocking stdin (EAGAIN) when `run` tasks in vite.config.ts use constantsAbiertopending triage
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
voidzero-dev/vite-plus#3155 ·
Los mantenedores suelen responder en 1 día
Todos los issues de voidzero-dev/vite-plus
Issues similares
-
llm translation
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
BerriAI/litellm#47884 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug(stubgen): `typing` / `_typeshed` imports are emitted above `from __future__ import annotations`Abiertostubgen
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 2 días
-
bug-hunt confirmed good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
area: pcb area: rendering priority: high status: needs-triage type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
-
Update webpki-root-certsAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
rustls/rustls-platform-verifier#262 · 2 comentarios · 2 reacciones ·