Avoid exposing internal Vite+ env vars via Vite env prefix

[crusty-voidzero]

Summary

After migrating Rolldown's CI to Vite+, tests started failing because Vite+ injects VITE_PLUS_* environment variables.

These variables may be picked up by Vite's env exposure logic because they start with VITE_:

• docs: https://vite.dev/config/shared-options#envprefix

This means they can end up included in bundled applications unexpectedly.

Repro / context

• Report from sapphi-red
• Failing run: https://github.com/rolldown/rolldown/actions/runs/23351281471/job/67930353118#step:8:482

Problem

Even if the current vars do not contain sensitive information, using the VITE_ prefix creates unnecessary risk and surprising behavior.

Suggested fix

Rename internal env vars to something that does not match Vite's default public env prefix, e.g.

• VITEPLUS_*
• or another non-VITE_ prefix

Expected outcome

Internal Vite+ env vars should not be accidentally exposed to application bundles via Vite's envPrefix behavior.

[claude]

Analysis

Understanding: Vite+ injects internal env vars into child processes (e.g., during vp run build). Because these vars use the VITE_PLUS_* / VITE_* prefix, Vite's default envPrefix: "VITE_" exposes them to bundled apps via import.meta.env. This is what broke Rolldown's CI — tests that use Vitest (which runs Vite internally) were seeing unexpected import.meta.env.VITE_PLUS_* values.

Relevant files

The env vars are centrally defined in:

• crates/vite_shared/src/env_vars.rs — single source of truth for all constant names
• crates/vite_shared/src/env_config.rs — reads vars into EnvConfig struct at startup

The problematic vars (all start with VITE_):

Variable	Category
VITE_PLUS_HOME	Config (user-facing, documented)
VITE_PLUS_NODE_VERSION	Config (user-facing)
VITE_PLUS_DEBUG_SHIM	Config
VITE_PLUS_ENV_USE_EVAL_ENABLE	Config
VITE_PLUS_BYPASS	Runtime (set on child processes)
VITE_PLUS_TOOL_RECURSION	Runtime (set on child processes)
VITE_PLUS_ACTIVE_NODE	Runtime (set on child processes)
VITE_PLUS_RESOLVE_SOURCE	Runtime (set on child processes)
VITE_PLUS_SHIM_TOOL	Runtime (set on child processes)
VITE_PLUS_SHIM_WRAPPER	Runtime (set on child processes)
VITE_PLUS_CLI_BIN	Runtime (set on child processes)
VITE_PLUS_GLOBAL_VERSION	Runtime (set on child processes)
VITE_PLUS_TRAMPOLINE_PATH	Testing
VITE_NODE_DIST_MIRROR	Config
VITE_UPDATE_TASK_TYPES	Config
VITE_GLOBAL_CLI_JS_SCRIPTS_DIR	Config
VITE_LOG	Config

The runtime vars (set on child processes) are the highest-risk group since they propagate into Vite's build environment.

TS-side usages are spread across:

• packages/cli/src/utils/constants.ts
• packages/tools/src/snap-test.ts
• packages/tools/src/install-global-cli.ts
• ecosystem-ci/patch-project.ts

Verdict: Fixable — medium complexity

The architecture is ideal for this fix: all var names flow from the single env_vars.rs file, so the rename is mechanical.

Implementation plan

1. Choose new prefix: I'd suggest VP_ for brevity (e.g., VP_HOME, VP_NODE_VERSION) or VITEPLUS_ to stay descriptive. VP_ is shorter and unambiguous.

2. Update crates/vite_shared/src/env_vars.rs: Rename all constants to use the new prefix (e.g., VITE_PLUS_HOME → VP_HOME).

3. Update crates/vite_shared/src/env_config.rs: The struct field names and from_env() reads update automatically since they reference the constants.

4. Update all Rust consumers — the compiler will catch every missed reference since they use typed constants, not string literals. Files affected: crates/vite_global_cli/, crates/vite_trampoline/, crates/vite_js_runtime/, crates/vite_install/, packages/cli/binding/.

5. Update TypeScript consumers (packages/cli/src/, packages/tools/src/, ecosystem-ci/): Rename string references and process.env.* accesses.

6. Update documentation (docs/guide/env.md) and GitHub Actions workflows (.github/workflows/).

7. Backward compat for user-facing vars (optional but recommended): Read both old and new name in from_env(), warn on old name, to give users a migration window. Most critical for VITE_PLUS_HOME and VITE_PLUS_NODE_VERSION which users may have in their shell profiles.

Concerns

• Breaking change for users who have VITE_PLUS_HOME / VITE_PLUS_NODE_VERSION in their environment. A deprecation shim in from_env() for a release cycle would ease this.
• Install scripts at vite.plus reference VITE_PLUS_VERSION — those would need coordinated updates.
• Snap test snap.txt files may need regeneration if any env var names appear in test output.

[fengmk2]

It seems that changing the prefix to VP_* would be better, as the command users run daily is vp, and seeing VP_HOME should naturally remind them of vp.

[jong-kyung]

@fengmk2 Hi! I'd like to work on this. I'll rename all VITE_PLUS_* env vars to use the VP_* prefix as suggested

[fengmk2]

@jong-kyung No problem, but this change will be a bit complex. You'll need to also look at https://github.com/voidzero-dev/vite-task vite-task, as there are related environment variables that need to be handled.

[jong-kyung]

@jong-kyung No problem, but this change will be a bit complex. You'll need to also look at https://github.com/voidzero-dev/vite-task vite-task, as there are related environment variables that need to be handled.

@fengmk2 Thanks for the heads-up about vite-task!
I traced the env flow and found thisvp build sets env: ["VITE_*"] as the fingerprinted env pattern.
After the rename, VP_VERSION won't match this VITE_* pattern, so it would be filtered out by vite-task's EnvFingerprints::resolve() and not passed to child processes.

My plan is to add "VP_*" to DEFAULT_UNTRACKED_ENV in vite-task/crates/vite_task_graph/src/config/mod.rs, so that internal VP_* vars are passed through without affecting cache keys. Does this approach sound right?

[fengmk2]

@jong-kyung looks fine, let's get started

[jong-kyung]

I've submitted the prerequisite PRs:

• vite-task: voidzero-dev/vite-task#297 — Add VP_* to DEFAULT_UNTRACKED_ENV (merged)
• vite-plus: #1155 — Bump vite-task rev

Once #1155 is merged, I'll submit the rename PR.