Skip to content

Windows: PowerShell installer (1.1.0) does not add vite-plus\bin to user PATH — 'vp' not recognized #2984

Open

Description

@dagilleland

Describe the bug

On Windows 11, installing Vite+ with the PowerShell installer completes, but the bin directory (%LOCALAPPDATA%\vite-plus\bin) is never added to the user PATH. In a new PowerShell session, vp is not found:

vp: The term 'vp' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

What I expect: after the installer finishes (and a new terminal is opened), vp resolves from PATH.

What actually happens: the install itself is fine. Every file is in place, state\self-setup\*.json was written, and running vp.exe by its full path works. But the user PATH (HKCU\Environment\Path) has no vite-plus entry. As far as I can tell from install.ps1, the PATH update is delegated to the vp self-setup handoff (Invoke-InstallHandoff); that step apparently ran but never persisted the user PATH change.

This looks similar to #973, but that was on 0.1.x and was fixed by upgrading. This is a fresh install of 1.1.0.

Reproduction

N/A. No project needed; this is a global install issue (steps below).

Steps to reproduce

  1. On Windows 11 Pro (build 26200), in PowerShell 7.1.4, run: irm https://vite.plus/ps1 | iex
  2. Open a new PowerShell window.
  3. Run vp help or vp env doctor. Result: "The term 'vp' is not recognized…"
  4. Run & "$env:LOCALAPPDATA\vite-plus\bin\vp.exe" env doctor. It works and reports the PATH problem:
PATH
  ✗ vp                not in PATH
  note: Run 'vp env setup' to create the vp shim.
  ✗ Shim dir          not in PATH
  note: Expected: C:\Users\<user>\AppData\Local\vite-plus\bin

(All Installation and Configuration checks pass, including shims.)

Possibly relevant: my existing user PATH is a REG_EXPAND_SZ value that contains an unexpanded variable entry (%PNPM_HOME%) and one empty entry (;;). Total length is about 817 characters. I haven't confirmed whether either of these affects the self-setup PATH write.

Workaround: manually prepend %LOCALAPPDATA%\vite-plus\bin to the user PATH and restart the terminal.

System Info

> vp env current
Node.js:
  Version    24.21.0
  Source     lts
  Bin Path   C:\Users\<user>\AppData\Local\vite-plus\data\js_runtime\node\24.21.0\node.exe
  Installed  true
  Mode       managed

> vp --version
vp v1.1.0

OS: Windows 11 Pro 10.0.26200
Shell: PowerShell 7.1.4

Used Package Manager

N/A (global install; no package manager selected yet)

Activity

  1. dagilleland commented on Oct 10, 2026

    @dagilleland
    Author

    Follow-up: the manual workaround worked, with one extra step.

    Prepending only %LOCALAPPDATA%\vite-plus\bin to the user PATH fixed vp itself. However, vp env doctor then reported a second missing entry:

    PATH
      ✓ vp                C:\Users\<user>\AppData\Local\vite-plus\bin\vp.exe
      ✓ Shim dir          C:\Users\<user>\AppData\Local\vite-plus\bin
      ✗ Fallback dir      not in PATH
    

    So the self-setup wrote neither PATH entry, bin (front) or data\fallback-bin (end). Also, the doctor message for the fallback dir doesn't say which directory to add. I found the expected layout (bin first, fallback last) in the PowerShell snippet embedded in vp.exe.

    After also appending %LOCALAPPDATA%\vite-plus\data\fallback-bin to the end of the user PATH (kept as REG_EXPAND_SZ) and opening a new terminal, vp env doctor reports "All checks passed".

    Full workaround for anyone else hitting this:

    $bin = "$env:LOCALAPPDATA\vite-plus\bin"
    $fb  = "$env:LOCALAPPDATA\vite-plus\data\fallback-bin"
    $old = (Get-Item HKCU:\Environment).GetValue('Path', '', 'DoNotExpandEnvironmentNames')
    Set-ItemProperty HKCU:\Environment -Name Path -Value "$bin;$old;$fb" -Type ExpandString
    # then restart your terminal(s)
  2. added a commit that references this issue on Oct 14, 2026
  3. fengmk2 commented on Oct 16, 2026

    @fengmk2
    Member

    @dagilleland #3012 (comment) Could you help verify this using the preview build version and check whether the issue has been fixed?

  4. self-assigned this
    on Oct 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Fields

Priority

None yet

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions