feat(env): add VP_ENV_FORBIDDEN to restrict Vite+ to system Node.js and package managers by myuron · Pull Request #3233 · voidzero-dev/vite-plus

myuron · 2026-10-25T14:41:09Z

Summary

Part of #1899 (letting NixOS and similar systems use only system Node.js and package managers). Follows #3143.

VP_ENV_FORBIDDEN=1 stops Vite+ from managing Node.js and every package-manager family. Vite+ then never downloads, reuses from the cache, or resolves over the network a managed runtime or package manager, whatever config.json or the VP_*_MANAGER variables say. Shims and the tools Vite+ selects itself use only the system tools on PATH.

VP_ENV_FORBIDDEN stays undocumented until the follow-up PR covers the remaining commands. Without it, nothing changes.

What's Changed

Switch and safety net

Only the exact value 1 enables it. It covers Node.js and all package-manager families; per-tool or mixed setups are not supported.
The managed entry points fail with DisabledByEnvForbidden before their cache lookups: the Node.js download and version index, the package-manager download, binary lookup and bootstrap, and registry version resolution.

Shims and tool selection

With VP_ENV_FORBIDDEN=1, the node and package-manager shims never search PATH or forward, including under VP_BYPASS.
- With managed config.json, the error suggests vp env off <component>.
- With system_first, reaching a shim means no system tool comes before it.
Where Vite+ selects a tool itself (vp env exec, vpx, global package binaries), it uses the first PATH match only. vp_command::classify_first_path_match reports a Vite+ shim or a managed install there as an error instead of skipping it.
Vite+ adds no managed directory to child PATHs.

Installers and vp upgrade

A vp without this change would ignore VP_ENV_FORBIDDEN and download managed tools, so installers and vp upgrade refuse such a target while it is set.

vp answers VP_SELF_SETUP_SUPPORT_CHECK=env-forbidden with a second line, vite-plus-self-setup-env-forbidden. The response to the existing check (vite-plus-self-setup-v1) is unchanged, because released installers compare it exactly.
install.sh, install.ps1, and vp_installer probe with the new value only when VP_ENV_FORBIDDEN=1, and fail before the legacy installer path.
vp upgrade checks the extracted binary before installing dependencies, and vp upgrade --rollback checks the previous version before switching.

Installation-time setup

First-start setup saves every component as system_first, even when VP_*_MANAGER=yes is set, so the shims sit after the system tools. The Homebrew setup does the same.
Vite+'s own dependencies are installed with the first node and pnpm on PATH, which must be system tools. Both tools and the release's engines.node are checked before the installation is changed. For vp upgrade, engines.node comes from the vite-plus metadata that is already fetched.
pnpm cannot download another pnpm: the wrapper package.json omits packageManager, and pnpm runs with --config.manage-package-manager-versions=false and --ignore-scripts. It gets the PATH used for the check, so its #!/usr/bin/env node finds the checked node.
VP_SETUP_NODE_VERSION is ignored with a warning.

This relaxes two guarantees from #3269, only when VP_ENV_FORBIDDEN=1 is set:

The exact installation Node.js (.node-version / vpNodeVersion) becomes any system Node.js that satisfies engines.node.
pnpm 10.34.7 becomes the system pnpm. If it cannot use the installation lockfile, the error and upgrade.log point to VP_SETUP_SKIP_INSTALL_LOCKFILE=1.

Scope

Follow-up PR:

Errors for commands that only make sense for managed tools, such as vp env use, vp env install, and vp env pin <version>.
Delegated commands (vp install, vp run, …) and status commands use the system tools without network resolution.
The local CLI, and documentation including the NixOS setup.

Until then, these commands download nothing: the delegated commands fail with DisabledByEnvForbidden.

Testing

just check, just lint, just test
Unit tests for the system-tool checks, the pnpm arguments and wrapper package.json, engines.node resolution, the cached pnpm bootstrap, the support probe, and vp upgrade keeping the current version when the system tools are rejected
Snapshot cases:
- shim_system_first_fallback: env_forbidden_overrides_managed_shims (unreachable Node.js mirror and registry; no managed install is created), env_forbidden_child_processes
- command_self_setup: command_self_setup_env_forbidden_probe, command_self_setup_env_forbidden_config, command_self_setup_env_forbidden_in_place (the system-tool check runs before setup changes anything)
- command_self_setup_external: command_self_setup_external_homebrew_env_forbidden
.github/scripts/test-install-bootstrap.sh, .github/scripts/test-install-bootstrap.ps1, and test-install-legacy-remote.ps1 cover the env-forbidden scenarios (CI)
Windows (CI)

Some existing command_self_setup and shim snapshot cases fail locally on NixOS before and after this change (same cases), so CI covers them.

fengmk2 · 2026-10-27T06:33:31Z

@codex review

chatgpt-codex-connector · 2026-10-27T06:33:45Z

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-27T06:34:49.474516Z We couldn’t complete this review. Comment `@codex review` to try again.	`b15ffe5`	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

chatgpt-codex-connector · 2026-10-27T06:34:49Z

Codex Review: Something went wrong. Try again later by commenting “@codex review”.

An unknown error occurred

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

liangmiQwQ

(🙇 apogolise for late replying)

…rectory When the upgrade target was the retained previous version, the support probe ran after extracting into that directory, and the failed-install cleanup then deleted the rollback installation on refusal. Probe the binary from a temporary directory first so a refusal leaves every install directory unchanged.

…-only npm

…m-only

myuron · 2026-11-02T16:48:30Z

Design update: system-only shims fail instead of searching PATH

@fengmk2 @liangmiQwQ

Following the discussion in #3233 (comment) and #3233 (comment), I reworked how system-only behaves in shims and child processes. Several earlier replies in the review threads describe mechanisms that no longer exist, so here is the current design in one place. The branch is also rebased onto the current main.

System-only shims never search PATH or forward (6f58c4c)

A shim whose tool is system-only fails as soon as it is reached, under VP_BYPASS too. The shell only reaches a shim when no system tool comes before it on PATH.
With managed config.json (shims first on PATH), the error suggests vp env off <component> to move the shims after the system tools. Otherwise it says that no system tool comes before the shims.
This replaces the re-entry counter (VP_SYSTEM_ONLY_REENTRY). A manager that forwards back to Vite+ stops at the fallback shim on the first entry, so no loop can form.

Where vp picks a tool itself, it takes the first PATH match only (ca76a28, a4eb134)

vp env exec <tool> / vp node, vpx, global package binaries, and the Node.js that package-manager shims use classify the first PATH match (vp_command::classify_first_path_match): a system tool, a Vite+ shim, a Vite+-owned install, or nothing.
A system-only tool must be a system tool. A Vite+ shim or a managed install there fails instead of being skipped; a managed install is reported with its path and a pointer to vp env doctor.
npm on system-only Node.js follows its own mode, but the npm bundled with a managed runtime is rejected, since it would run managed Node.js. A pinned man
This replaces the identity-based lookup inside VP_BIN_DIR, which is no longer excluded as a whole, so a
foreign Node.js in a shared bin is selecte

Child PATH: nothing is removed; managed em-only npm (97f6d08)

The child-PATH removal (restrict_child_env) is gone. Entries inherited from a parent stay as they are.
While npm is system-only, the shims no l directory, which would expose its bundlednpm. Children then resolve node from PATH, normally through its shim, and a nested npm no longer sees the
bundled npm: it resolves from PATH as the en it comes before the shims).

Global packages (fb64f12)

vp install -g, vp update -g, and vp outdated -g use the npm bundled with managed Node.js, so they now fail when npm is system-only, before any runt.

shim_system_first_fallback covers these ncluding #!/usr/bin/env node shebangs,nested npm, VP_BYPASS, and a managed runtime inherited first on PATH.

Follow-up PRs will cover vp env on (an error for a system-only component), vp env doctor (reporting these
states), and the remaining vp commands.

The rebase changed the hashes cited in my d0ed914, 6fb3e80 → 7e9cc00, c120e6c →6b5d4fa7, 6fe9fbe → ac7e269, e4491da → 83eab53 (the upgrade fix is unchanged).

liangmiQwQ · 2026-11-02T22:05:24Z

+///
+/// On failure, returns the user-facing messages, each printed with a `vp: `
+/// prefix. This function never executes the tool, so it can be tested directly.
+async fn select_core_tool(


Generally speaking, for Nix, are all tools set to system-only mode, or is it still possible to enable managed mode for some of them?

The reason I ask about that is there we imported too much complexity for the case: node is in managed while pnpm is system_only.

I'm wondering if system-only should be allowed only when neither of the two tools is in managed mode.

On NixOS, I expect mixed configurations involving a managed tool to be uncommon, since Vite+ managed binaries generally won't run without nix-ld.
The specific combination you mentioned (node=managed, pnpm=system-only) is therefore unlikely to be useful there.

On macOS or non-NixOS distributions using Nix, that dynamic-linker constraint often doesn't apply, so mixed modes can work.
I don't know of a concrete use case for mixing modes when using Nix.
The per-tool controls were intended to avoid coupling the behavior to NixOS and to preserve flexibility. That said, if supporting combinations like this adds significant complexity, I'm open to constraining them.

Would you prefer independent per-tool settings, or an explicit constraint between Node and the package-manager mode?

I am revisiting the entire discussion related to Nix support, and it turns out the issue might be more complex than I initially thought. I may need a bit more time before I make a detailed plan. (🙇 Really sorry!)

fengmk2 · 2026-11-03T10:56:18Z

~~@myuron Need to write user documentation for this new feature.~~

system-only is intentionally undocumented until the remaining paths are covered (vp commands, reinstall/upgrade dependency installation, and installation-time setup). Without a system-only variable, nothing changes: yes/no, config.json modes, and the existing installer probe response behave as before.

I miss this description. ignore my request.

fengmk2

LGTM.

Needs @liangmiQwQ ’s final approval.

liangmiQwQ

cc @myuron

After learning about what Nix users actually need on Vite+ side.

As vp env off already works with Nix, what users want is a env var which controls the status, if system-only is only allowed after running vp env off, it'll actually deviate from our original intention.
I haven't find cases where users need different states of different tools, either. Nix itself is just an environment manager, I believe users should not mix these features. Supporting this already brings some inconsistency and complexity.

So, I have two suggestions here:

Revert to the previous logic, where system-only doesn't conflict with managed mode. I've done some local experiments: If any issues arise, we can fix them by splitting the directory.
Instead of having VP_*_MANAGER for every single component, I think it's better to intro a new VP_ENV_FORBIDDEN=1 as the only main switch.

🙇 I'm really sorry that we proposed some flawed solutions, because of the lack a sufficient understanding of the Nix at the time. Thanks for your time!

…er VP_ENV_FORBIDDEN

# Conflicts: # crates/vp_global_cli/src/self_setup.rs # crates/vp_setup/src/install.rs

…_ENV_FORBIDDEN

…m pnpm

…him case

myuron · 2026-11-05T18:13:42Z

Design update: `VP_ENV_FORBIDDEN` replaces `VP_*_MANAGER=system-only`

@fengmk2 @liangmiQwQ

Following #3233 (review) and the agreement in #3233 (comment) / #3233 (comment), this PR is now rebuilt around a single switch, VP_ENV_FORBIDDEN=1. Review threads before this comment discuss the per-component system-only design, which is gone. The earlier approval was for that design, so I moved the PR back to draft and will ask for a new review when the scope below is complete. The new commits are stacked on top without a force push.

Per-component system-only removed (ab7703b, 8798016)

The family-specific precedence, the managed npm checks on system-only Node.js, and the vp install -g npm check are removed with their tests.
VP_NODE_MANAGER, VP_PM_MANAGER, and VP_<FAMILY>_MANAGER accept only yes / no again, as on main. They are install-time choices saved to config.json.

VP_ENV_FORBIDDEN=1 (c768665)

Only the exact value 1 enables it. It covers Node.js and every package-manager family. Per-tool or mixed setups are not supported.
No managed runtime or package manager is downloaded, reused from the cache, or resolved over the network, whatever config.json says. The download and registry-resolution entry points fail first.
Where vp selects a tool itself (vp env exec, vpx, package binaries), it uses the first PATH match only, as in the previous design. A Vite+ shim or a managed install there is an error, not something to skip. vp adds no managed directory to child PATHs.
The installers and vp upgrade refuse a target that does not support VP_ENV_FORBIDDEN, using an additional probe value. The vite-plus-self-setup-v1 response is unchanged.

Core shims fail instead of searching PATH

With VP_ENV_FORBIDDEN=1, the node and package-manager shims never search PATH or forward, under VP_BYPASS too. With managed config.json the error suggests vp env off <component>. With system_first, reaching a shim means no system tool comes before it.
This differs from @liangmiQwQ's suggestion to keep forwarding and split directories if problems appear. Forwarding from a shim is how node shim loops forever in system-first mode when the system node is a mise shim (vp and shell node hang) #2728 looped (removed in feat(env): separate system-first shims from the main bin directory #2758), and the same concern was raised in feat(env): add VP_ENV_FORBIDDEN to restrict Vite+ to system Node.js and package managers #3233 (comment). Failing immediately cannot loop, even when a system tool forwards back to Vite+.

Install time (d76d9a3, 8bfb442)

First-start setup saves every component as system_first, even when VP_*_MANAGER=yes is set, so the shims sit after the system tools.
Vite+'s own dependencies are installed with the first node and pnpm on PATH, which must be system tools. Both tools and the release's engines.node are checked before the installation is touched. For vp upgrade, engines.node comes from the vite-plus metadata that is already fetched. A Vite+ shim first on PATH is an error that suggests vp env off.
pnpm cannot download another pnpm: the wrapper package.json omits packageManager, and pnpm runs with --config.manage-package-manager-versions=false. It also runs with --ignore-scripts, which matches the pinned pnpm 10 not running dependency build scripts. pnpm gets the PATH used for the check, so its #!/usr/bin/env node finds the checked node.
VP_SETUP_NODE_VERSION is ignored with a warning.
The branch now merges main (fb62f10). The Homebrew setup added there also checks the system tools before it saves preferences, and the pnpm bootstrap it introduced is guarded like the other download paths (389ff25, f3c81b1).

This relaxes two guarantees from #3269 when VP_ENV_FORBIDDEN=1 is set:

the exact installation Node.js (.node-version / vpNodeVersion) becomes "any system Node.js that satisfies engines.node"
pnpm 10.34.7 becomes the system pnpm. If it cannot use the installation lockfile, the error points to VP_SETUP_SKIP_INSTALL_LOCKFILE=1.

Without this, installation under VP_ENV_FORBIDDEN=1 would have to download Node.js and pnpm, or fail. Users who set it have chosen the system tools, so the relaxation applies only to them.

Scope

This PR: the above, plus errors for commands that only make sense for managed tools (vp env use, vp env install, vp env pin <version>, …), which I am still working on.
Next PR: delegated commands (vp install, vp run, …) and status commands use the system tools without network resolution; the local CLI; documentation, including the NixOS setup. Until then, the delegated commands fail with a "not managed" error under VP_ENV_FORBIDDEN=1 and download nothing. They are separate to keep this PR reviewable.

liangmiQwQ · 2026-11-05T21:53:13Z

@myuron could you update PR description and PR title as well?

myuron · 2026-11-06T00:41:57Z

@myuron could you update PR description and PR title as well?

@liangmiQwQ
Thanks for checking! I've updated the title and description.

liangmiQwQ

The direction and implement LGTM 💯 (sorry for late responding)

This differs from @liangmiQwQ's suggestion to keep forwarding and split directories if problems appear. Forwarding from a shim is how node shim loops forever in system-first mode when the system node is a mise shim (vp and shell node hang) #2728 looped (removed in feat(env): separate system-first shims from the main bin directory #2758), and the same concern was raised in feat(env): add VP_ENV_FORBIDDEN to restrict Vite+ to system Node.js and package managers #3233 (comment). Failing immediately cannot loop, even when a system tool forwards back to Vite+.

I'm okay if Nix users are also okay with that tradeoff.

fengmk2

LGTM

github-actions · 2026-11-09T02:07:59Z

Preview binary sizes (`759196d`)

Compared with the latest stable release, v1.5.0. Preview build.
Each row measures one binary. Negative changes mean a smaller preview binary.

Binary	Latest release	Preview	Change
`vp` (macOS ARM64)	5.42 MiB	5.44 MiB	+16.48 KiB (+0.30%)
NAPI (macOS ARM64)	42.98 MiB	42.98 MiB	0 B (0.00%)
`vp` (macOS x64)	6.89 MiB	6.91 MiB	+24.20 KiB (+0.34%)
NAPI (macOS x64)	48.23 MiB	48.23 MiB	+16 B (+0.00%)
`vp` (Linux ARM64 GNU)	6.87 MiB	6.90 MiB	+32.02 KiB (+0.46%)
NAPI (Linux ARM64 GNU)	32.24 MiB	32.21 MiB	-32.03 KiB (-0.10%)
`vp` (Linux ARM64 musl)	6.94 MiB	6.98 MiB	+32.31 KiB (+0.45%)
NAPI (Linux ARM64 musl)	31.44 MiB	31.44 MiB	+3.00 KiB (+0.01%)
`vp` (Linux x64 GNU)	8.31 MiB	8.34 MiB	+32.02 KiB (+0.38%)
NAPI (Linux x64 GNU)	36.39 MiB	36.13 MiB	-265.44 KiB (-0.71%)
`vp` (Linux x64 musl)	8.37 MiB	8.41 MiB	+34.15 KiB (+0.40%)
NAPI (Linux x64 musl)	35.35 MiB	35.35 MiB	+3.00 KiB (+0.01%)
`vp` (Windows x64)	6.15 MiB	6.18 MiB	+34.00 KiB (+0.54%)
NAPI (Windows x64)	31.97 MiB	31.98 MiB	+7.00 KiB (+0.02%)
Trampoline (Windows x64)	13.00 KiB	13.00 KiB	0 B (0.00%)
Installer (Windows x64)	4.66 MiB	4.67 MiB	+10.00 KiB (+0.21%)
`vp` (Windows ARM64)	5.39 MiB	5.41 MiB	+27.50 KiB (+0.50%)
NAPI (Windows ARM64)	28.27 MiB	28.27 MiB	+6.50 KiB (+0.02%)
Trampoline (Windows ARM64)	13.00 KiB	13.00 KiB	0 B (0.00%)
Installer (Windows ARM64)	3.84 MiB	3.85 MiB	+7.50 KiB (+0.19%)

gzip -9 sizes

Binary	Latest release	Preview	Change
`vp` (macOS ARM64)	3.23 MiB	3.24 MiB	+14.70 KiB (+0.44%)
NAPI (macOS ARM64)	18.64 MiB	18.64 MiB	+1.16 KiB (+0.01%)
`vp` (macOS x64)	3.41 MiB	3.43 MiB	+11.75 KiB (+0.34%)
NAPI (macOS x64)	19.87 MiB	19.88 MiB	+1.83 KiB (+0.01%)
`vp` (Linux ARM64 GNU)	3.73 MiB	3.74 MiB	+12.80 KiB (+0.34%)
NAPI (Linux ARM64 GNU)	13.72 MiB	13.71 MiB	-12.80 KiB (-0.09%)
`vp` (Linux ARM64 musl)	3.75 MiB	3.76 MiB	+17.13 KiB (+0.45%)
NAPI (Linux ARM64 musl)	13.41 MiB	13.41 MiB	+3.78 KiB (+0.03%)
`vp` (Linux x64 GNU)	3.80 MiB	3.81 MiB	+13.25 KiB (+0.34%)
NAPI (Linux x64 GNU)	14.55 MiB	14.40 MiB	-154.45 KiB (-1.04%)
`vp` (Linux x64 musl)	3.82 MiB	3.83 MiB	+16.32 KiB (+0.42%)
NAPI (Linux x64 musl)	14.08 MiB	14.08 MiB	+247 B (+0.00%)
`vp` (Windows x64)	2.84 MiB	2.86 MiB	+16.95 KiB (+0.58%)
NAPI (Windows x64)	13.09 MiB	13.09 MiB	+2.38 KiB (+0.02%)
Trampoline (Windows x64)	7.14 KiB	7.14 KiB	+1 B (+0.01%)
Installer (Windows x64)	2.23 MiB	2.24 MiB	+5.16 KiB (+0.23%)
`vp` (Windows ARM64)	2.72 MiB	2.73 MiB	+13.13 KiB (+0.47%)
NAPI (Windows ARM64)	12.42 MiB	12.42 MiB	+1.01 KiB (+0.01%)
Trampoline (Windows ARM64)	6.93 KiB	6.93 KiB	0 B (0.00%)
Installer (Windows ARM64)	2.13 MiB	2.13 MiB	+6.13 KiB (+0.28%)

Raw sizes are uncompressed file sizes. gzip sizes recompress each binary at level 9; they are not package or download archive sizes.
The baseline uses published release files, including NAPI packages from npm at the same version. Build versions and toolchains can affect the difference.

github-actions · 2026-11-09T02:10:32Z

Registry bridge build (`759196d`)

Warning

This build is from the fork myuron/vite-plus and has not been reviewed.
Installing it runs that code on your machine. Build log

This commit build is published to the registry bridge, which serves these as ordinary npm versions (every other package proxies to npmjs):

Package	Version
`vite-plus`	`0.0.0-commit.759196d2423a2f8608b35cbe21626d06e6d37f59`
`@voidzero-dev/vite-plus-core`	`0.0.0-commit.759196d2423a2f8608b35cbe21626d06e6d37f59`
`create-vite-plus`	`0.0.0-commit.759196d2423a2f8608b35cbe21626d06e6d37f59`

Install the Vite+ CLI built from this commit, then migrate a project:

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/myuron/vite-plus/759196d2423a2f8608b35cbe21626d06e6d37f59/packages/cli/install.sh | VP_PR_VERSION=3233 VP_LEGACY_INSTALLER_URL=https://raw.githubusercontent.com/myuron/vite-plus/759196d2423a2f8608b35cbe21626d06e6d37f59/packages/cli/install-legacy.sh bash

# Windows (PowerShell)
$env:VP_PR_VERSION="3233"; $env:VP_LEGACY_INSTALLER_URL="https://raw.githubusercontent.com/myuron/vite-plus/759196d2423a2f8608b35cbe21626d06e6d37f59/packages/cli/install-legacy.ps1"; irm https://raw.githubusercontent.com/myuron/vite-plus/759196d2423a2f8608b35cbe21626d06e6d37f59/packages/cli/install.ps1 | iex

Or install with Homebrew (macOS / glibc Linux):

These commands use the formula and binary from this published commit. Replace brew install with brew reinstall if the tap package is already installed.
If Homebrew Core’s vite-plus is installed, run brew uninstall vite-plus first. This keeps your user data; do not run vp implode to switch installations.

(
  set -eu
  export HOMEBREW_NO_AUTO_UPDATE=1
  export HOMEBREW_VP_PR_VERSION=759196d2423a2f8608b35cbe21626d06e6d37f59
  brew tap voidzero-dev/vite-plus https://github.com/voidzero-dev/vite-plus
  preview_tap="$(brew --repository voidzero-dev/vite-plus)"
  git -C "$preview_tap" fetch --depth=1 https://github.com/myuron/vite-plus.git "$HOMEBREW_VP_PR_VERSION"
  git -C "$preview_tap" switch --detach "$HOMEBREW_VP_PR_VERSION"
  brew install voidzero-dev/vite-plus/vp
  brew test voidzero-dev/vite-plus/vp
  "$(brew --prefix)/bin/vp"
)

The tap stays at the tested commit. Return it to main after testing:

git -C "$(brew --repository voidzero-dev/vite-plus)" switch main

Or download the standalone Windows installer built from this commit:

Architecture	Installer
x64	`vp-setup-x86_64-pc-windows-msvc.exe`
Arm64	`vp-setup-aarch64-pc-windows-msvc.exe`

GitHub requires you to sign in and downloads each installer as a ZIP artifact. Extract vp-setup.exe, then run it against this preview build:

.\vp-setup.exe --version "0.0.0-commit.759196d2423a2f8608b35cbe21626d06e6d37f59" --registry "https://registry-bridge.viteplus.dev/"

After installing, upgrade the current project's vite-plus to this test build with:

vp migrate

Or create a new project from this commit without installing the CLI:

export npm_config_registry=https://registry-bridge.viteplus.dev/ pnpm_config_registry=https://registry-bridge.viteplus.dev/
pnpm create vite-plus@0.0.0-commit.759196d2423a2f8608b35cbe21626d06e6d37f59 # or: npm create vite-plus@0.0.0-commit.759196d2423a2f8608b35cbe21626d06e6d37f59

$env:npm_config_registry="https://registry-bridge.viteplus.dev/"; $env:pnpm_config_registry="https://registry-bridge.viteplus.dev/"
pnpm create vite-plus@0.0.0-commit.759196d2423a2f8608b35cbe21626d06e6d37f59 # or: npm create vite-plus@0.0.0-commit.759196d2423a2f8608b35cbe21626d06e6d37f59

pnpm 11+ reads pnpm_config_registry, npm and older pnpm read npm_config_registry. The new project pins this build, so keep the registry set for later installs, or configure it as below.

Or point your package manager at the bridge registry https://registry-bridge.viteplus.dev/:

Package manager	Registry config
npm / pnpm / Bun	`.npmrc`: `registry=https://registry-bridge.viteplus.dev/`
Yarn (v2+)	`.yarnrc.yml`: `npmRegistryServer: "https://registry-bridge.viteplus.dev/"`

Then pin the build (vite aliases to vite-plus-core; pnpm can use a catalog, npm an overrides entry):

{
  "devDependencies": {
    "vite-plus": "0.0.0-commit.759196d2423a2f8608b35cbe21626d06e6d37f59",
    "vite": "npm:@voidzero-dev/vite-plus-core@0.0.0-commit.759196d2423a2f8608b35cbe21626d06e6d37f59"
  }
}

myuron · 2026-11-09T15:24:55Z

@fengmk2
Merged the latest 'main' to resolve the conflict with #3400.
No behavior change to this PR. The failing CLI snapshot jobs time out while downloading pnpm/bun, which main has also hit since #3400.

liangmiQwQ self-requested a review October 25, 2026 14:55

fengmk2 reviewed Oct 27, 2026

View reviewed changes

Comment thread crates/vp_global_cli/src/shim/dispatch.rs Resolved

fengmk2 reviewed Oct 27, 2026

View reviewed changes

Comment thread crates/vp_global_cli/src/shim/dispatch.rs Resolved

fengmk2 reviewed Oct 27, 2026

View reviewed changes

Comment thread crates/vp_global_cli/src/shim/dispatch.rs Resolved

fengmk2 reviewed Oct 27, 2026

View reviewed changes

Comment thread crates/vp_global_cli/src/commands/upgrade/mod.rs Resolved

liangmiQwQ reviewed Oct 27, 2026

View reviewed changes

Comment thread crates/vp_global_cli/src/shim/dispatch.rs Resolved

Comment thread crates/vp_global_cli/src/shim/dispatch.rs Resolved

myuron force-pushed the feat/system-only-shim branch from e4491da to 1d90f21 Compare November 2, 2026 15:46

myuron added 14 commits November 3, 2026 01:08

feat(env): guard managed downloads under system-only

823d980

feat(shim): use only system tools under system-only

9111d54

feat(setup): require system-only support from targets

0ae0cb4

fix(shim): restore shim error prefixes and stabilize CI checks

0173f16

fix(shim): enforce system-only restrictions in child process PATH

9d0ed91

fix(vpx): skip managed installs for system-only tools

7e9cc00

fix(shim): stop system-only loops through forwarding tools

6b5d4fa

fix(shim): keep foreign tools in a shared bin eligible under system-only

ac7e269

refactor(command): classify the first PATH match for system tools

ca76a28

fix(shim): fail system-only shims instead of forwarding to PATH

6f58c4c

fix(shim): select system-only tools by the first PATH match

a4eb134

fix(shim): stop adding managed Node.js directories that expose system…

97f6d08

…-only npm

fix(global): reject managed npm for global packages when npm is syste…

fb64f12

…m-only

myuron force-pushed the feat/system-only-shim branch from 1d90f21 to fb64f12 Compare November 2, 2026 16:29

liangmiQwQ reviewed Nov 2, 2026

View reviewed changes

fengmk2 approved these changes Nov 3, 2026

View reviewed changes

liangmiQwQ suggested changes Nov 3, 2026

View reviewed changes

myuron added 2 commits November 6, 2026 02:07

feat(setup): save every component as system_first under VP_ENV_FORBIDDEN

d76d9a3

feat(setup): install Vite+ dependencies with system node and pnpm und…

8bfb442

…er VP_ENV_FORBIDDEN

myuron marked this pull request as draft November 5, 2026 17:11

myuron added 5 commits November 6, 2026 02:50

Merge remote-tracking branch 'upstream/main' into feat/system-only-shim

fb62f10

# Conflicts: # crates/vp_global_cli/src/self_setup.rs # crates/vp_setup/src/install.rs

fix(setup): check system tools before setup changes anything under VP…

389ff25

…_ENV_FORBIDDEN

fix(pm): guard the pnpm bootstrap under VP_ENV_FORBIDDEN

f3c81b1

fix(setup): keep upgrade.log lockfile hints consistent with the syste…

6ba1d09

…m pnpm

test(snapshots): skip package-manager prewarm for the env-forbidden s…

7f0efc0

…him case

myuron marked this pull request as ready for review November 5, 2026 18:14

myuron changed the title ~~feat(env): honor system-only in shims and installers~~ feat(env): add VP_ENV_FORBIDDEN to restrict Vite+ to system Node.js and package managers Nov 6, 2026

fengmk2 reviewed Nov 6, 2026

View reviewed changes

Comment thread crates/vp_global_cli/src/commands/env/exec.rs Resolved

fix(env): check the child Node.js under VP_ENV_FORBIDDEN

dfebbec

myuron force-pushed the feat/system-only-shim branch from ee5b2cf to dfebbec Compare November 6, 2026 16:22

liangmiQwQ self-requested a review November 7, 2026 14:31

liangmiQwQ approved these changes Nov 8, 2026

View reviewed changes

liangmiQwQ assigned fengmk2 Nov 8, 2026

Merge branch 'main' into feat/system-only-shim

759196d

fengmk2 approved these changes Nov 9, 2026

View reviewed changes

fengmk2 added test: e2e Auto run e2e tests test: install-e2e run vite install e2e test test: create-e2e Run `vp create` e2e tests test: sfw preview-build Publish this PR's commits to the registry bridge as preview builds labels Nov 9, 2026

Merge branch 'main' into feat/system-only-shim

e8e2d8b

Conversation

myuron commented Oct 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

What's Changed

Scope

Testing

Uh oh!

fengmk2 commented Oct 27, 2026

Uh oh!

chatgpt-codex-connector Bot commented Oct 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codex Review Summary

Uh oh!

chatgpt-codex-connector Bot commented Oct 27, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

liangmiQwQ left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

myuron commented Nov 2, 2026

Design update: system-only shims fail instead of searching PATH

Uh oh!

liangmiQwQ Nov 2, 2026

Choose a reason for hiding this comment

Uh oh!

myuron Nov 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

liangmiQwQ Nov 3, 2026

Choose a reason for hiding this comment

Uh oh!

fengmk2 commented Nov 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fengmk2 left a comment

Choose a reason for hiding this comment

Uh oh!

liangmiQwQ left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

myuron commented Nov 5, 2026

Design update: VP_ENV_FORBIDDEN replaces VP_*_MANAGER=system-only

Uh oh!

liangmiQwQ commented Nov 5, 2026

Uh oh!

myuron commented Nov 6, 2026

Uh oh!

Uh oh!

liangmiQwQ left a comment

Choose a reason for hiding this comment

Uh oh!

fengmk2 left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Nov 9, 2026

Preview binary sizes (759196d)

Uh oh!

github-actions Bot commented Nov 9, 2026

Registry bridge build (759196d)

Uh oh!

myuron commented Nov 9, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

myuron commented Oct 25, 2026 •

edited

Loading

chatgpt-codex-connector Bot commented Oct 27, 2026 •

edited

Loading

myuron Nov 3, 2026 •

edited

Loading

fengmk2 commented Nov 3, 2026 •

edited

Loading

liangmiQwQ left a comment •

edited

Loading

Design update: `VP_ENV_FORBIDDEN` replaces `VP_*_MANAGER=system-only`

Preview binary sizes (`759196d`)

Registry bridge build (`759196d`)