Support `devEngines` field

[yinhx3]

Description

I suggest that Vite Plus support the devEngines field.
I use pnpm as both my package manager and Node manager. Since pnpm added support for devEngines.runtime, I’ve been managing my project’s Node version through this field.

Currently, Vite Plus relies on non-standard solutions like the packageManager field or .node-version file. I recommend adopting the general devEngines field for better consistency and interoperability.

Suggested solution

• Support devEngines.runtime for Node version management
• Support devEngines.packageManager to declare the package manager

Alternative

No response

Additional context

• pnpm support for devEngines.runtime
• npm docs: devEngines in package.json

Validations

• Read the Contributing Guidelines.
• Confirm this request is for Vite+ itself and not for Vite, Vitest, tsdown, Rolldown, or Oxc.
• Check that there isn't already an issue requesting the same feature.

[fengmk2]

vp Node version management will reads from .node-version, pkg#engines.node, or pkg#devEngines.runtime (in priority order).

[yinhx3]

Alright. Perhaps the documentation could use some updates.
Also, I believe it would be more convenient if vp env pin defaulted to configuring devEngines.runtime.

[fengmk2]

Support devEngines.packageManager to declare the package manager

This is missing, we will support it.

[rteobaldo]

vp Node version management will reads from .node-version, pkg#engines.node, or pkg#devEngines.runtime (in priority order).

Since devEngines.runtime is the standard defined by npm and already being primarialy used by pnpm shouldn't it be the higher priority over other methods? I agree we should support community patterns but I think it's also to push defined standards over those patterns if possible.

[rsimp]

Does vp allow individual updates to oxfmt, oxlint, vitest and vite or the vp cli? If not, shouldn't vp handle pinning itself?

vp could use a global installation but also shim local versions inside VITE_PLUS_HOME/bin. This would help in the long run as projects age and eventually depend on deprecated features. It would avoid ending up with a bunch of vp version managers.

[fengmk2]

@rsimp Add the vite-plus dependency to the project devDependencies, so you can manage the vite-plus version at the project level.
The global vp CLI is a tool similar to node and npm, which in most cases can be installed once and remain without updates for a period of time. Commands executed through the global vp CLI will attempt to find if the current project has a vite-plus dependency, and if so, will proxy the command to it.
You can refer to https://github.com/voidzero-dev/vibe-dashboard/blob/main/package.json#L16

[mfsbo]

I use volta to pin versions and it looks like this in package.json while packageManager entry is made under it with the package name and version as one string. If vite-plus has to manage pinning then using vite-plus as key for an object similar to vola will make sense so any package and version can be pinned inside it.

"volta": {
    "node": "25.6.1",
    "npm": "11.12.1"
  },
  "packageManager": "npm@11.12.1"

[will-stone]

I would have to vote against that idea: no more standards please. devEngines is the standard. And it currently works really nicely with switching Node version automatically when cd’ing around projects, using SemVer to pick the most appropriate version. Let’s let the vp devs support it too for the package manager and (hopefully) stop auto setting the pinned field in package.json 🙏