`vp env exec` / `vp node` ignore `nodeShimMode: system_first`, download a managed runtime (~192 MB) that `vp env clean` then refuses to remove
Los mantenedores suelen responder en 1 día
Evaluación
Este issue todavía no se ha evaluado.
Descripción
Summary
With nodeShimMode: system_first, vite-plus correctly resolves Node.js to the system runtime for the shims and for vp env current / vp env which. The vp env exec family -- which vp node is a shorthand for -- does not honour that preference: it resolves and downloads a vite-plus managed Node runtime instead.
This is not a matter of preference between two managed versions. It is a divergence between what vite-plus reports and what it dispatches, plus disk growth on a machine that explicitly opted out of Node management.
Expected vs actual
Configuration:
{
"nodeShimMode": "system_first",
"packageManagerShimModes": { "bun": "system_first", "npm": "system_first",
"pnpm": "system_first", "yarn": "system_first" }
}
What agrees with system_first:
$ node -v
v26.11.1
$ vp env which node
/usr/bin/node
$ vp env current
Node.js:
Version 26.11.1
Source system PATH
Bin Path /usr/bin/node
Mode system_first
What does not:
$ vp node -v
v24.22.0
$ vp env exec node -v
v24.22.0
vp env exec --help states:
--node <NODE>Node.js version to use (e.g., "20.18.0", "lts", "^20.0.0"). If omitted and command is node/npm/npx or a global package binary, version is resolved automatically (same as shim behavior)
The shim resolves to the system Node, so env exec is not resolving "the same as shim behavior".
Reproduction
Deterministic container, Docker or Podman:
https://gist.github.com/Kat404/0c2bf9a8f0a6942f216a827098e3a24d
podman build -t vp-sysfirst-exec .
podman run --rm vp-sysfirst-exec
CASE A: DIVERGENCE CONFIRMED shim=v20.19.2 vp-node=v24.22.0
CASE B: 201708991 bytes on disk under js_runtime/node
CASE C: inventory tracks it as: * v24.22.0 current
CASE D: inventory does record it, so uninstall (not clean) is the only removal
CASE E: vp env clean -> ✓ Removed 0 Node.js runtimes
The build fails if the divergence does not reproduce.
Manually, without a container:
vp env off node
vp env off pm
mkdir -p /tmp/repro && cd /tmp/repro
printf '{\n "name": "repro",\n "version": "1.0.0",\n "private": true\n}\n' > package.json
node -v # system version
vp env which node # /usr/bin/node
vp node -v # vite-plus managed version
Consequences
-
Unwanted download. Running
vp node(orvp env exec node) materialises a managed runtime of roughly 190-220 MB on a machine configured to use the system Node. -
vp env cleancannot reclaim it. Once downloaded, the runtime is recorded as the current version:
$ vp env list
Node.js
* v24.22.0 current
$ vp env clean
✓ Removed 0 Node.js runtimes
Per the docs, vp env clean preserves the current and configured-default versions. So the space comes back every time a project invokes vp node, and the only removal is the explicit vp env uninstall 24.22.0.
- Confusing state.
vp env listreports* v24.22.0 currentwhilevp env currentreports the system26.11.1as the resolved environment. Two commands, two different "current" Node runtimes.
Possible fixes
- Resolve
env execthrough the same path the shims use, sonodeShimMode: system_firstapplies to it too. - Or: when a runtime is materialised only as an
env execfallback while the environment is system-first, do not record it as the current install, sovp env cleancan remove it.
Related, not duplicates
- #2642 - Concurrent
vp run devprocesses download the same Node.js runtime twice. Same subsystem, different symptom. - #2728 -
nodeshim loops forever in system-first mode when the systemnodeis a mise shim. Same mode, different failure. - #2746 / #2758 - Separate
system-firstshims from the main bin directory (merged; this is whybin/now holds onlyvp,vpr,vpxand the rest live infallback-bin/, appended to PATH).
Environment
- vite-plus v1.3.0 (
vp upgrade --checkreports already up to date) - Arch Linux, kernel 6.x
- System Node.js: v26.11.1 at
/usr/bin/node(pacmannodejs) - Container repro: debian:stable-slim with Debian
nodejsv20.19.2 at/usr/bin/node, vite-plus installed viacurl -fsSL https://vite.plus | bash - Podman 6.1.4
- Lenguaje dominante
- Rust
- Estrellas
- 6.3k
- Forks
- 283
- Merge medio
- 1 d 14 h
- PR fusionados (30 d)
- 208
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
-
contribution welcome
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
voidzero-dev/vite-plus#3096 · 1 comentario · 3 reacciones ·
Los mantenedores suelen responder en 1 día
-
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
-
pending triage
Dificultad 3/5 Medio día Aptitud para principiantes 78/100
voidzero-dev/vite-plus#3110 ·
Los mantenedores suelen responder en 1 día
-
pending triage
Dificultad 5/5 Más de una semana Aptitud para principiantes 28/100
voidzero-dev/vite-plus#3107 · 1 reacción ·
Los mantenedores suelen responder en 1 día
Todos los issues de voidzero-dev/vite-plus
Issues similares
-
documentation P2
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
bug good first issue priority:high
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Konfirm-xyz/konfirm-contracts#163 ·
Los mantenedores suelen responder en 1 día
-
area:gc-repack-output bug factory:dogfood factory:triaged priority:p3 type:bug type:ux
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
gitbutlerapp/grit#1161 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
feature performance
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
lance-format/lance#10137 ·
Los mantenedores suelen responder en 2 días