Add Git Bash (Windows) support to the CLI

[wtto00]

Describe the bug

I'm using Git Bash on Windows, and I've set export VITE_PLUS_HOME="/d/home/.vite-plus" in my ~/.bash_profile.

After successfully installing via curl -fsSL https://vite.plus | bash, running the vp command resulted in a command not found error.

I fixed this by changing __vp_bin="D:/home/.vite-plus\bin" to __vp_bin="/d/home/.vite-plus/bin" in /d/home/.vite-plus/env. After refreshing the environment with source ~/.bash_profile, the vp command was recognized.

However, running vp create threw the following error:

node:internal/modules/cjs/loader:1459
  throw err;
  ^

Error: Cannot find module 'D:\home\.vite-plus\node_modules\vite-plus\dist\bin.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1456:15)
    at defaultResolveImpl (node:internal/modules/cjs/loader:1066:19)
    at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1071:22)
    at Module._load (node:internal/modules/cjs/loader:1242:25)
    at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
    at Module.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:154:5)
    at node:internal/main/run_main_module:33:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

I then updated __vp_bin in /d/home/.vite-plus/env from "/d/home/.vite-plus/bin" to "/d/home/.vite-plus/current/bin", which allowed the vp create command to proceed interactively.

New Issue: When creating a Library project using vp create, it fails during the Generating project stage. The logs are as follows:

VITE+ - The Unified Toolchain for the Web

  Vite+ Library

◇ Package name:
  vp-demo

◇ Which package manager would you like to use?
  pnpm

◇ Which agents are you using?
  OpenCode

◇ Which editor are you using?
  VSCode

◇ Set up pre-commit hooks to run formatting, linting, and type checking with auto-fixes?
  Yes

◐  Generating project (5s)
ENOENT: no such file or directory, open 'D:\projects\work\vp-demo\package.json'
Error: ENOENT: no such file or directory, open 'D:\projects\work\vp-demo\package.json'
    at Object.readFileSync (node:fs:440:20)
    at readJsonFile (file:///D:/home/.vite-plus/0.1.12/node_modules/.pnpm/vite-plus@0.1.12_vite@8.0.0/node_modules/vite-plus/dist/global/json-BRdVJ52a.js:130:21)
    at editJsonFile (file:///D:/home/.vite-plus/0.1.12/node_modules/.pnpm/vite-plus@0.1.12_vite@8.0.0/node_modules/vite-plus/dist/global/json-BRdVJ52a.js:144:27)
    at setPackageName (file:///D:/home/.vite-plus/0.1.12/node_modules/.pnpm/vite-plus@0.1.12_vite@8.0.0/node_modules/vite-plus/dist/global/create.js:3237:2)
    at executeBuiltinTemplate (file:///D:/home/.vite-plus/0.1.12/node_modules/.pnpm/vite-plus@0.1.12_vite@8.0.0/node_modules/vite-plus/dist/global/create.js:3489:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
    at async main (file:///D:/home/.vite-plus/0.1.12/node_modules/.pnpm/vite-plus@0.1.12_vite@8.0.0/node_modules/vite-plus/dist/global/create.js:4134:12) {
  errno: -4058,
  code: 'ENOENT',
  syscall: 'open',
  path: 'D:\\projects\\work\\vp-demo\\package.json'
}
Failed to generate code: ENOENT: no such file or directory, open 'D:\projects\work\vp-demo\package.json'

■ Canceled (0s)

Reproduction

none

Steps to reproduce

No response

System Info

VITE+ - The Unified Toolchain for the Web

Environment:
  Version  24.14.0
  Source   lts

Tool Paths:
  node  D:/home/.vite-plus\js_runtime\node\24.14.0\node.exe
  npm   D:/home/.vite-plus\js_runtime\node\24.14.0\npm.cmd
  npx   D:/home/.vite-plus\js_runtime\node\24.14.0\npx.cmd

Used Package Manager

pnpm

Logs

Validations

• Read the Contributing Guidelines.
• Check that there isn't already an issue for the same bug.
• Confirm this is a Vite+ issue and not an upstream issue (Vite, Vitest, tsdown, Rolldown, or Oxc).
• The provided reproduction is a minimal reproducible example.

[fengmk2]

The custom VITE_PLUS_HOME environment variable is currently an internal parameter, originally intended for local development of vite-plus.
Modifying its default value may very likely cause unexpected behavior, as we have not conducted correctness testing for this behavior.

[wtto00]

@fengmk2 It's not an issue with VITE_PLUS_HOME. I removed it and performed a completely fresh installation, but I'm still encountering the same issue mentioned above.

[claude]

Analysis

I've investigated the codebase and found two distinct bugs in this report. Here's what's happening and how to fix them.

---

Bug 1: env file generates Windows-style paths, breaking Git Bash

File: crates/vite_global_cli/src/commands/env/setup.rs — create_env_files() (lines 384–392)

On Windows, bin_path.as_path().display() produces backslash paths like D:\home\.vite-plus\bin. When this is written into the POSIX env shell script as __vp_bin="D:\home\.vite-plus\bin", Git Bash cannot use it to extend PATH.

Fix: When generating the POSIX env file on Windows, convert the path to forward slashes. The expected value in the env file should be D:/home/.vite-plus/bin (which Git Bash can handle), not D:\home\.vite-plus\bin.

---

Bug 2: vp create library template fails with ENOENT

Files:

• crates/vite_install/src/shim.rs — sh_shim() (lines 36–57)
• packages/cli/src/create/templates/builtin.ts — executeBuiltinTemplate() (lines 30–46)
• packages/cli/src/create/utils.ts — setPackageName() (lines 101–106)

Root cause in sh_shim: The MSYS/MINGW branch does cygpath -w "$basedir", which converts the bin directory to a Windows path (e.g., D:\home\.vite-plus\bin). This causes Node.exe to be invoked with a Windows path context, so process.cwd() inside Node returns D:\projects\work (Windows-style) and path.join uses backslashes.

Root cause in executeBuiltinTemplate: The library template is scaffolded via runRemoteTemplateCommand (which runs pnpm dlx degit sxzz/tsdown-templates/vite-plus <targetDir>). If this command fails for any reason, the exit code is not checked before setPackageName is called — so the code tries to read a package.json that was never created:

const result = await runRemoteTemplateCommand(...);
// no exitCode check here!
const fullPath = path.join(workspaceInfo.rootDir, templateInfo.targetDir);
setPackageName(fullPath, templateInfo.packageName); // throws ENOENT

The same unguarded pattern exists for all other template types in executeBuiltinTemplate (lines 50–59).

---

Is this fixable? Yes

Implementation Plan

Step 1 — Fix path generation in env file (crates/vite_global_cli/src/commands/env/setup.rs)

In create_env_files, normalize backslashes to forward slashes when embedding paths in the POSIX env file:

bin_path.as_path().display().to_string().replace('\\', "/")

Or add a dedicated display_posix() method to vite_path and use it here.

Step 2 — Fix sh_shim for Git Bash (crates/vite_install/src/shim.rs)

The current cygpath -w converts to Windows paths for all CYGWIN/MINGW/MSYS environments. For Git Bash (MINGW/MSYS), MSYS2 can execute native Windows binaries using POSIX paths, so the conversion is not needed and causes Node to operate in Windows path mode. Consider limiting cygpath -w to CYGWIN only:

case `uname` in
    *CYGWIN*)
        if command -v cygpath > /dev/null 2>&1; then
            basedir=`cygpath -w "$basedir"`
        fi
    ;;
esac

Warning: This needs careful testing — the goal is for Node to keep POSIX-style process.cwd() in Git Bash.

Step 3 — Guard setPackageName with exit code check (packages/cli/src/create/templates/builtin.ts)

Add a check before calling setPackageName so failures surface cleanly:

const result = await runRemoteTemplateCommand(...);
if (result.exitCode !== 0) {
  return { ...result, projectDir: templateInfo.targetDir };
}
const fullPath = path.join(workspaceInfo.rootDir, templateInfo.targetDir);
setPackageName(fullPath, templateInfo.packageName);

Apply the same guard to the non-library template path (lines 50–59).

---

Potential Concerns

• The sh_shim change (Step 2) needs real Windows + Git Bash testing to confirm node.exe is still found correctly without cygpath -w for MINGW/MSYS.
• Step 1 alone may fix the first reported symptom (missing vp command after install).
• Step 3 would at least surface a cleaner error for vp create failures rather than a confusing ENOENT.
• There may be additional path-handling issues in other commands once install is fixed, so end-to-end testing on Git Bash is recommended.

Complexity: Medium — the env file fix (Step 1) is straightforward; the sh_shim change (Step 2) requires careful validation.