chore: update Vite+ env var prefixes

.claude/skills/add-ecosystem-ci/SKILL.md

@@ -27,7 +27,7 @@ Fetch the repository's root to check if the main package.json is in a subdirecto
 
 ### 2.2 Check if Project Already Uses Vite-Plus
 
-Check the project's root `package.json` for `vite-plus` in `dependencies` or `devDependencies`. If the project already uses vite-plus, set `forceFreshMigration: true` in `repo.json`. This tells `patch-project.ts` to set `VITE_PLUS_FORCE_MIGRATE=1` so `vp migrate` forces full dependency rewriting instead of skipping with "already using Vite+".
+Check the project's root `package.json` for `vite-plus` in `dependencies` or `devDependencies`. If the project already uses vite-plus, set `forceFreshMigration: true` in `repo.json`. This tells `patch-project.ts` to set `VP_FORCE_MIGRATE=1` so `vp migrate` forces full dependency rewriting instead of skipping with "already using Vite+".
 
 ### 2.3 Auto-detect Commands from GitHub Workflows
 
@@ -145,5 +145,5 @@ vp run build
 - The `directory` field is optional - only add it if the package.json is not in the project root
 - If `directory` is specified in repo.json, it must also be specified in the workflow matrix
 - `patch-project.ts` automatically handles running `vp migrate` in the correct directory
-- `forceFreshMigration` is required for projects that already have `vite-plus` in their package.json — it sets `VITE_PLUS_FORCE_MIGRATE=1` so `vp migrate` forces full dependency rewriting instead of skipping
+- `forceFreshMigration` is required for projects that already have `vite-plus` in their package.json — it sets `VP_FORCE_MIGRATE=1` so `vp migrate` forces full dependency rewriting instead of skipping
 - OS exclusions are added to the existing `exclude` section in the workflow matrix

crates/vite_shared/src/home.rs

@@ -107,7 +107,7 @@ mod tests {
             std::env::set_var("PATH", &new_path);
         }
 
-        // Clear any existing VITE_PLUS_HOME env var by using a test config without it
+        // Clear any existing VP_HOME env var by using a test config without it
         EnvConfig::test_scope(EnvConfig::for_test(), || {
             // Test: get_vp_home should return /tmp/xxx/.vite-plus
             let home = get_vp_home().unwrap();

rfcs/cli-output-polish.md

@@ -143,12 +143,12 @@ info(
 Where `VITE_PLUS_VERSION` is the vite-plus package version, injected via:
 
 - A new constant in `vite/packages/vite/src/node/constants.ts`, or
-- Read from an environment variable set by the Rust CLI before spawning vite (e.g., `VITE_PLUS_VERSION`)
+- Read from an environment variable set by the Rust CLI before spawning vite (e.g., `VP_VERSION`)
 
-**Recommended approach:** Environment variable injection. The Rust NAPI binding in `packages/cli/binding/src/cli.rs` already merges environment variables when spawning sub-tools via `merge_resolved_envs()`. We add `VITE_PLUS_VERSION` to the env map, and read it in vite:
+**Recommended approach:** Environment variable injection. The Rust NAPI binding in `packages/cli/binding/src/cli.rs` already merges environment variables when spawning sub-tools via `merge_resolved_envs()`. We add `VP_VERSION` to the env map, and read it in vite:
 
 ```javascript
-const VITE_PLUS_VERSION = process.env.VITE_PLUS_VERSION || VERSION;
+const VITE_PLUS_VERSION = process.env.VP_VERSION || VERSION;
 ```
 
 This is clean: the vite source change is minimal (reads an env var with fallback), and the version injection happens in the Rust layer that already owns this responsibility.
@@ -307,11 +307,11 @@ Historical context (no longer applies): Vitest was bundled (not cloned source) v
 After `bundleVitest()` copies vitest files to `dist/`, a `brandVitest()` step patches the cac chunk (`dist/chunks/cac.*.js`) with string replacements:
 
 1. `cac("vitest")` → `cac("vp test")` — CLI name shown in banner and help output
-2. `var version = "<semver>"` → `var version = process.env.VITE_PLUS_VERSION || "<semver>"` — runtime version injection via env var
+2. `var version = "<semver>"` → `var version = process.env.VP_VERSION || "<semver>"` — runtime version injection via env var
 3. `/^vitest\/\d+\.\d+\.\d+$/` regex → `/^vp test\/[\d.]+$/` — so the help callback can still find the banner line
 4. `$ vitest --help --expand-help` → `$ vp test --help --expand-help` — hardcoded help text
 
-The Rust NAPI binding injects `VITE_PLUS_VERSION` env var (same mechanism used for vite build/dev/preview commands), so `vp test -h` shows `vp test/<vite-plus-version>`.
+The Rust NAPI binding injects `VP_VERSION` env var (same mechanism used for vite build/dev/preview commands), so `vp test -h` shows `vp test/<vite-plus-version>`.
 
 #### 3.3 Remaining `vite` → `vp` branding in CLI output
 
@@ -379,7 +379,7 @@ Migrate JS-side code (`migration/bin.ts`, `create/bin.ts`) to use these shared f
 
 ### D3: Inject version via environment variable
 
-**Decision:** The Rust CLI sets `VITE_PLUS_VERSION` env var before spawning vite. The modified vite source reads it with a fallback.
+**Decision:** The Rust CLI sets `VP_VERSION` env var before spawning vite. The modified vite source reads it with a fallback.
 
 **Rationale:** This avoids hardcoding the version in vite source (which would require updating on every release). The Rust CLI already manages environment variables for sub-tool spawning via `merge_resolved_envs()`. The env var approach is the minimal-touch change to vite.
 
@@ -429,7 +429,7 @@ These are internal identifiers, API references, or project name references:
 
 ### Phase 1: vite Rebranding
 
-1. Add `VITE_PLUS_VERSION` env var injection in `packages/cli/binding/src/cli.rs` for vite commands (build, dev, preview)
+1. Add `VP_VERSION` env var injection in `packages/cli/binding/src/cli.rs` for vite commands (build, dev, preview)
 2. Modify `vite/packages/vite/src/node/cli.ts` — read env var, change banner text
 3. Modify `vite/packages/vite/src/node/build.ts` — change build banner text
 4. Modify `vite/packages/vite/src/node/logger.ts` — change default prefix

rfcs/dev-engines.md

@@ -53,7 +53,7 @@ Spec semantics that matter for this RFC:
 
 **Node.js resolution chain** (`crates/vite_global_cli/src/commands/env/config.rs`, `crates/vite_js_runtime/src/runtime.rs`):
 
-1. `VITE_PLUS_NODE_VERSION` env var (session)
+1. `VP_NODE_VERSION` env var (session)
 2. `~/.vite-plus/.session-node-version` (session)
 3. `.node-version` (walk up)
 4. `package.json#engines.node` (walk up)
@@ -127,7 +127,7 @@ Parsing rules:
 
 Proposed chain (change marked):
 
-1. `VITE_PLUS_NODE_VERSION` env var (session)
+1. `VP_NODE_VERSION` env var (session)
 2. `.session-node-version` (session)
 3. `.node-version` (walk up)
 4. **`package.json#devEngines.runtime[name="node"]` (walk up)** (moved above `engines.node`)
@@ -373,7 +373,7 @@ A small shared Rust helper (in `vite_shared`) will own "edit one field in packag
 - Managing non-Node runtimes (`deno`, `bun` as a runtime) via `devEngines.runtime`.
 - Validating `devEngines.os` / `cpu` / `libc`.
 - Acting as a general enforcement layer for arbitrary package manager names beyond pnpm / yarn / npm / bun.
-- Changing session-override behavior (`vp env use`, `VITE_PLUS_NODE_VERSION`).
+- Changing session-override behavior (`vp env use`, `VP_NODE_VERSION`).
 
 ## Deferred / Future Work