Repository navigation
Concurrent vp run dev processes download the same Node.js runtime twice #2642
Description
Describe the bug
When running vp run dev from two separate repositories that require the same managed Node.js version, Vite+ downloads the same Node.js runtime independently for each process instead of coordinating the installation and reusing the shared runtime.
The two repositories are unrelated (API and web), but both resolve to the same Vite+ managed runtime location under the user-level Vite+ directory.
This suggests that the runtime itself is intentionally shared globally, but concurrent vp processes may both observe the runtime as missing and start their own download/install operation.
Expected behavior
If multiple vp processes require the same Node.js version concurrently, only one process should download/install the runtime. Other processes should wait for the installation to complete and then reuse the same runtime.
Conceptually:
API vp run dev ──┐
├── shared runtime lock ──> download Node 24.21.0 once
Web vp run dev ──┘ └─> both reuse it
Actual behavior
Both projects trigger a Node.js download even though they resolve to the same shared managed runtime.
Environment
OS: Windows 11
Node runtime reported by Vite+:
VITE+ - The Unified Toolchain for the Web
Environment:
Version 24.21.0
Source lts
Tool Paths:
node C:\Users\<username>\.vite-plus\js_runtime\node\24.21.0\node.exe
npm C:\Users\<username>\.vite-plus\js_runtime\node\24.21.0\npm.cmd
npx C:\Users\<username>\.vite-plus\js_runtime\node\24.21.0\npx.cmd
Why this seems like a Vite+ issue
The managed Node runtime is stored in a user-level shared location rather than inside either repository. Therefore, downloading the same runtime independently for concurrent projects appears unnecessary and can waste bandwidth and startup time.
A related issue, #2449, shows that vp run provisions managed Node.js runtimes, but that issue concerns interrupted downloads rather than concurrent deduplication:
#2449
Suggested solution
Add cross-process synchronization around managed Node.js runtime installation, keyed by runtime/platform/version. For example, a filesystem lock around the shared runtime directory could allow one process to perform the download while other processes wait and then reuse the installed runtime.
Validations
- Checked the existing Vite+ issues for a duplicate report.
- Confirmed both projects resolve to the same global managed Node.js runtime.
- This appears specific to Vite+'s managed runtime provisioning rather than the projects themselves.
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Activity
akim136 commentedon Sep 17, 2026
Had a look at this because I was thinking of picking it up, and the design already exists in the repo.
rfcs/js-runtime.mdhas "Acquire file lock (prevent concurrent installs)" as step 5 of the install flow, a "Concurrent Download Protection" section describing file-based locking plus a re-check of the cache after acquiring the lock, and a concurrent-download case in its test plan. So this looks less like a feature request and more like a gap between the RFC and what shipped.What I cannot tell from outside is how much of it landed.
crates/vp_js_runtime/Cargo.tomlpulls intempfile, so the atomic-rename half seems to be there, but I do not see a file-locking crate listed. That could just mean it is done withstddirectly, or that the lock step is not wired up yet.Would you welcome a PR adding cross-process locking around managed runtime install, keyed by runtime/platform/version the way @tnp03 describes? The RFC says "same pattern as PackageManager", so I would follow that if you can point me at where it lives.
Happy to leave it alone if this is already in flight or you would rather design it in-house. Just wanted to ask before setting up the Rust toolchain for it.
liangmiQwQ commentedon Sep 26, 2026
Thanks for that! Since Vite+ is now on RC, you can start implementing it, but this might be handled after version 1.0.
chore(deps): update rust crates (#1780)