Support strict pnpm peer validation with the required Vite core alias #2806

This issue was opened by an AI agent on behalf of @chenxin-yan.

Description

Following up on #1021: could Vite+ support pnpm's strict peer validation without blanket peerDependencyRules.allowAny / allowedVersions: '*' exceptions?

I understand the workaround in #1021 is intentional. This request is specifically about retaining compatibility checks, not just hiding the warning: we want compatible Vite consumers to install while a genuinely incompatible Vite plugin still fails validation.

The required alias exposes @voidzero-dev/vite-plus-core@1.0.0-rc.0 as vite. Its published manifest declares bundled Vite 8.3.0, but pnpm compares the wrapper's 1.0.0-rc.0 version with consumers' Vite peer ranges. This also occurs with the bundled/aligned Vitest, without a framework or application.

This is a packaging/integration support request, not evidence of a Vite/Vitest runtime incompatibility or a demonstrated pnpm regression.

Reproduction

Tested on Linux x86_64 (NixOS), Nix-provided Node 24.20.0 LTS and pnpm 12.3.4, project-local Vite+ 1.0.0-rc.0, matching core 1.0.0-rc.0, and Vitest 5.0.1. No global Vite+ manager, dependency patches, peer-rule exceptions or application code.

In a fresh empty directory:

package.json:

{
  "name": "vite-plus-strict-peers-repro",
  "private": true,
  "type": "module",
  "packageManager": "pnpm@12.3.4",
  "devDependencies": {
    "vite-plus": "1.0.0-rc.0",
    "vite": "npm:@voidzero-dev/vite-plus-core@1.0.0-rc.0",
    "vitest": "5.0.1"
  }
}

pnpm-workspace.yaml:

strictPeerDependencies: true
overrides:
  'vite@*': npm:@voidzero-dev/vite-plus-core@1.0.0-rc.0
  'vitest@*': 5.0.1

Run:

pnpm install --ignore-scripts
pnpm peers check

Both commands exit 1. Installation reports:

[ERR_PNPM_PEER_DEP_ISSUES] Unmet peer dependencies

✕ unmet peer vite
  Installed: 1.0.0-rc.0
  Wanted:
    "^6.0.0 || ^7.0.0 || ^8.0.0":
      @vitest/mocker@5.0.1
    "^6.4.0 || ^7.0.0 || ^8.0.0":
      vitest@5.0.1

Lifecycle scripts were disabled to keep this metadata-only reproduction bounded; no application build or runtime assertion is involved.

Suggested solution

An officially maintained integration that preserves validation against the supported bundled Vite version, rather than requiring broad peer-check suppression. I am not prescribing a particular implementation; this may require packaging changes or coordination with pnpm.

Useful acceptance cases would be:

• Compatible consumers of bundled Vite 8 install with strict peer checks enabled.
• A consumer requiring only Vite 7 remains rejected.
• The documented core alias and a single aligned Vitest runtime are preserved.

If there is already a supported strict-validation configuration, please point me to it. Otherwise, please document the limitation and required suppression explicitly in the manual-installation instructions.

Alternatives considered

• The allowAny workaround in vp update warns about issues with vite peer dependency #1021 addresses the warning but loses the compatibility check this request is about.
• Narrow local peer exceptions or a .pnpmfile manifest rewrite would move ongoing compatibility policy into each consumer; we would prefer an upstream-supported solution.
• Installing ordinary Vite independently to satisfy the peers would defeat the documented core-alignment requirement.

Additional context

• Manual installation and alias/Vitest alignment
• Documented pnpm @* override keys
• Published core manifest, including bundledVersions
• Shipped migration source: rewritePnpmWorkspaceYaml adds managed keys to both allowAny and allowedVersions: '*'; pnpmPeerDependencyRulesSatisfyVitePlus requires those settings. Thus running the migrator does not preserve the requested validation.

Validations

• Read the contributing guidelines.
• This request concerns Vite+'s packaging/integration policy, not an underlying compiler/runtime failure.
• Checked for an existing request; vp update warns about issues with vite peer dependency #1021 is related and closed with the workaround, while this follow-up requests preservation of strict validation.