You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
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.0asvite. 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:Run:
Both commands exit 1. Installation reports:
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:
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
allowAnyworkaround invp updatewarns about issues withvitepeer dependency #1021 addresses the warning but loses the compatibility check this request is about..pnpmfilemanifest rewrite would move ongoing compatibility policy into each consumer; we would prefer an upstream-supported solution.Additional context
@*override keysbundledVersionsrewritePnpmWorkspaceYamladds managed keys to bothallowAnyandallowedVersions: '*';pnpmPeerDependencyRulesSatisfyVitePlusrequires those settings. Thus running the migrator does not preserve the requested validation.Validations
vp updatewarns about issues withvitepeer dependency #1021 is related and closed with the workaround, while this follow-up requests preservation of strict validation.