Force to use a compatible version for `vp upgrade`

[liangmiQwQ]

Describe the bug

Reference #1865 (comment)

vp upgrade now uses the node version resolved from session env var, project configure, which may be not compatible with Vite+'s requirement in package.json#engines.node. That will cause pnpm skip installing the optional binary files that makes Vite+ broken.

We should always use a compatible node version for vp upgrade, just like delegate_to_global_cli. Maybe we can reuse ensure_cli_runtime function but it also needs changing (Embed requirement at buildtime instead of reading at runtime, similar to #1412

Reproduction

This can be reproduced by following the steps given in the vite-plus's source code repo.

Steps to reproduce

1. Cd into the current vite-plus repo
2. Run pnpm boostrap-cli && vp env use 20.0.0
3. Run vp upgrade
4. Run vp commands like vp pack, vp build

[fengmk2]

Maybe we should force to use Node.js LTS version to run vp upgrade, just like the first install by install.sh
https://github.com/voidzero-dev/vite-plus/blob/main/packages/cli/install.sh#L954

[wyf027]

I traced the upgrade path a bit, and I think the risky hop is the inner install rather than only the outer vp upgrade command.

vp upgrade extracts the new version, writes the wrapper package, then install_production_deps() runs the newly extracted {version_dir}/bin/vp install with cwd set to that wrapper directory. Since the wrapper directory contains a package.json, package-manager command setup can still go through package/project runtime resolution for that inner install.

A narrow fix could be to make the generated wrapper package.json declare the same Node runtime floor/range as the CLI package, or an explicit LTS alias if the intended policy is to match the first install path. That would keep the change local to the upgrade/install wrapper and avoid changing normal project package-manager commands.

Does that match the direction you want, or should vp upgrade bypass project runtime resolution for the inner install and force the CLI/LTS runtime at the command execution layer instead?

[liangmiQwQ]

A narrow fix could be to make the generated wrapper package.json declare the same Node runtime floor/range as the CLI package, or an explicit LTS alias if the intended policy is to match the first install path. That would keep the change local to the upgrade/install wrapper and avoid changing normal project package-manager commands.

No, it should not be in this way, VP_NODE_VERSION and .session-node-version have higher priority than package.json. Sorry for late respond, I will handle it asap.