fix: more safer Vite+ global install and vp upgrade

[kazupon]

Summary

related issues and PRs

• vp upgrade fails when minimumReleaseAge is configured #1260
• fix(upgrade): bypass package manager release age gates during vp upgrade #1272
• curl -fsSL https://vite.plus | bash fails silently when vp install encounters an error #833
• fix(cli): show errors when vp install fails and bypass npm & pnpm minimum release age #834

This updates the release-age handling for the Vite+ global install/upgrade path so we no longer silently bypass package manager protections.

Users who configure pnpm minimumReleaseAge are explicitly trying to reduce supply-chain risk from newly published compromised packages.

Instead of always writing minimum-release-age=0, Vite+ now first runs the wrapper install normally.

If pnpm blocks the install with a release-age error, Vite+ only writes the local override and retries after an interactive, default-No confirmation.

The same behavior is applied to the standalone install scripts, including install.ps1 and install.sh.

Changes

• Remove unconditional minimum-release-age=0 override from vp upgrade and standalone installers.
• Detect pnpm release-age failures from ERR_PNPM_NO_MATURE_MATCHING_VERSION, minimumReleaseAge messages, and guarded ERR_PNPM_NO_MATCHING_VERSION cases.
• Prompt users with a default-No warning before disabling release-age protection for this Vite+ install only.
• Keep non-interactive environments blocked instead of adding a bypass flag or env var.
• Preserve install.log / upgrade.log visibility for failure diagnosis.
• Avoid passing --silent to the inner captured vp install, because pnpm suppresses the release-age error body in silent mode.
• Add comments with pnpm source references explaining the release-age detection signals.

[netlify]

✅ Deploy Preview for viteplus-preview canceled.

Name	Link
🔨 Latest commit	63c54eb
🔍 Latest deploy log	https://app.netlify.com/projects/viteplus-preview/deploys/69d65a1ffa54c6000841f72e

[fengmk2]

@cpojer @TheAlexLichter Should the first-time installation of Vite+ follow this config as well? Wouldn’t that feel a bit strange?

[TheAlexLichter]

Yes, I would honor the settings for the first time install as well.

[fengmk2]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 63c54eb115

ℹ️ 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]

Hey guys, I am handling the package manager refactor (#2406) these days and noticed that. In my opinion, this is quite odd, and we should probably reconsider about that.

First, I want to argue that the reason we call pnpm here is not to download a new package, it is install the vite-plus, a part of our global cli, vp setup itself. Using pnpm and other pm here is just to reuse the functions, as Vite+ is totally able to download the package itself. Most users even don't know there is an internal package manager call, they will feel strange when receiving this prompt.

Second, this doesn't make sense for Vite+ itself's internal installation semantically. Unlike pnpm install, who needs --latest to upgrade the latest version, vp upgrade's default target is always the newest one, users who run that already decided to use the new Vite+ version.

Third, if we indeed want to add a safety guard, the timing is not right. vite-plus package download happens after the corresponding vp binary downloads, and the layout is already set. We should either ask users if they want to install the latest version before anything happens; the current approach requires rolling back the installation state later, and the next installation also needs to consider the residual state, which greatly increases the complexity.

[kazupon]

Thanks for the comment!

I take the core point to be: this is not a user-project pnpm install, yet we overlay the internal pnpm minimumReleaseAge gate after the fact, and only prompt after we have already created a partial install.

As long as we use pnpm here, we still have to handle the cooldown. Dropping pnpm and fetching vite-plus dependencies ourselves would mean Vite+ also owns dependency resolution and cooldown, which is out of scope for now.

So I think it is enough to fix only the timing of the prompt, rather than removing pnpm or writing our own resolver.

I also agree we should not carry this after-the-fact prompt, retry, and partial rollback into the #2611 self-setup. Asking before setup starts fits that unification better.

[liangmiQwQ]

@kazupon Thank you!

I don't think replacing pnpm with a custom resolver is the right direction, either. What I mean is that pnpm is used here mainly for convenience and performance, and the user is completely unaware of it.

For this question, I suggest directly bypassing pnpm's minimumReleaseAge gate, and removing this users prompt.

On the one hand, vp upgrade is semantically different from pnpm install, which I've mentioned in #1338 (comment).

Second, this doesn't make sense for Vite+ itself's internal installation semantically. Unlike pnpm install, who needs --latest to upgrade the latest version, vp upgrade's default target is always the newest one, users who run that already decided to use the new Vite+ version.

On the other hand, if we move this prompt before everything starts, we have to read users' settings or set a random number, as vp binary itself is downloaded without any package manager. We have to care about pnpm11+'s default setting and other edge cases. So vite-plus downloading, who will really trigger minimumReleaseAge, has still to be bypassed.

Would it be okay?

[liangmiQwQ]

/cc @TheAlexLichter