chore(deps-dev): bump vite-plus from 0.1.13 to 0.1.17#1454
chore(deps-dev): bump vite-plus from 0.1.13 to 0.1.17#1454dependabot[bot] wants to merge 1 commit intomainfrom
Conversation
Bumps [vite-plus](https://github.com/voidzero-dev/vite-plus/tree/HEAD/packages/cli) from 0.1.13 to 0.1.17. - [Release notes](https://github.com/voidzero-dev/vite-plus/releases) - [Commits](https://github.com/voidzero-dev/vite-plus/commits/v0.1.17/packages/cli) --- updated-dependencies: - dependency-name: vite-plus dependency-version: 0.1.17 dependency-type: direct:development ... Signed-off-by: dependabot[bot] <support@github.com>
| "vite": "npm:@voidzero-dev/vite-plus-core@0.1.13", | ||
| "vite-bundle-analyzer": "^1.3.6", | ||
| "vite-plugin-mkcert": "^1.17.10", | ||
| "vite-plus": "0.1.13", | ||
| "vite-plus": "0.1.17", | ||
| "vitest": "npm:@voidzero-dev/vite-plus-test@0.1.13" | ||
| }, | ||
| "config": { |
There was a problem hiding this comment.
🔴 The pnpm.overrides (and the direct vite/vitest devDependencies) were not updated alongside the vite-plus bump from 0.1.13 to 0.1.17, causing both @voidzero-dev/vite-plus-core@0.1.13 and @0.1.17 to be installed simultaneously. This split-brain setup means the vp CLI runs build/test operations with core@0.1.17 internally while all project imports of vite/vitest still resolve to 0.1.13 via the override; the pnpm.overrides and pinned devDependencies should be updated from 0.1.13 to 0.1.17 to restore consistency.
Extended reasoning...
What the bug is: This PR bumps the vite-plus CLI from 0.1.13 to 0.1.17 but leaves three related entries at 0.1.13: the direct vite devDependency (npm:@voidzero-dev/vite-plus-core@0.1.13), the direct vitest devDependency (npm:@voidzero-dev/vite-plus-test@0.1.13), and both entries in pnpm.overrides. The result is that both @voidzero-dev/vite-plus-core@0.1.13 and @voidzero-dev/vite-plus-core@0.1.17 end up installed in the same node_modules tree simultaneously.
The specific code path: vite-plus@0.1.17 carries @voidzero-dev/vite-plus-core@0.1.17 and @voidzero-dev/vite-plus-test@0.1.17 as direct (non-peer) dependencies, so pnpm installs them regardless of the overrides. The overrides only control how the vite/vitest peer slots are satisfied. The lockfile snapshot for @voidzero-dev/vite-plus-test@0.1.17 makes this plain: it lists '@voidzero-dev/vite-plus-core': 0.1.17 as its own direct dependency while simultaneously listing vite: '@voidzero-dev/vite-plus-core@0.1.13' as the resolved peer — two different versions of the same package in the same closure.
Why existing code doesn't prevent it: The pnpm.overrides mechanism redirects package names (the bare vite/vitest identifiers) to the pinned aliases, but it cannot override what vite-plus-test itself depends on directly by its real package name @voidzero-dev/vite-plus-core. pnpm therefore installs both and does not error because both are valid resolutions in their respective dependency trees.
What the impact would be: The 0.1.17 release notes explicitly mention an upstream toolchain upgrade (vite 8.0.8, rolldown 1.0.0-rc.15, etc.), meaning the internal APIs of vite-plus-core@0.1.17 may differ from 0.1.13. Any user code or configuration that imports vite (e.g. vite.config.ts) continues to get 0.1.13, while the CLI dispatches builds and tests using 0.1.17 internally. This version skew can silently cause plugin API mismatches, config option differences, or subtle test runner behavioural changes that are hard to diagnose.
How to fix it: Update package.json in three places: change the vite devDependency to npm:@voidzero-dev/vite-plus-core@0.1.17, change the vitest devDependency to npm:@voidzero-dev/vite-plus-test@0.1.17, and update both pnpm.overrides entries to 0.1.17. Then re-run pnpm install to regenerate the lockfile with a single consistent version of the core.
Step-by-step proof:
vite-plus@0.1.17package.json depends directly on@voidzero-dev/vite-plus-core@0.1.17and@voidzero-dev/vite-plus-test@0.1.17.- The project's
pnpm.overridesmapsvite → npm:@voidzero-dev/vite-plus-core@0.1.13andvitest → npm:@voidzero-dev/vite-plus-test@0.1.13. - pnpm resolves the project's own
vite/vitestslots to 0.1.13 (override applies), but must also satisfyvite-plus's transitive deps under their real package names — so 0.1.17 of both also gets installed. - The lockfile confirms the dual installation:
@voidzero-dev/vite-plus-core@0.1.13and@voidzero-dev/vite-plus-core@0.1.17both appear in the snapshots section. - Inside the
@voidzero-dev/vite-plus-test@0.1.17snapshot, thevitepeer resolves to@voidzero-dev/vite-plus-core@0.1.13— confirming the split-brain: the test runner uses core@0.1.17 for its own internals but exposes core@0.1.13 as thevitepeer to user code.
Addressing the refutation: The refutation argues that this is intentional design — the CLI can be versioned independently from the core packages. While pnpm does not error on this combination, the vite-plus ecosystem (the vp upgrade command, official migration docs) consistently treats the CLI, core, and test packages as a matched set. Additionally the 0.1.17 release includes non-trivial toolchain upgrades (new rolldown, new vite major patch) making version skew between the CLI and the peer-resolved core genuinely risky, not merely cosmetic.
There was a problem hiding this comment.
I believe this was pinned in f113363 due to broken native binding. We can restore it once we confirm that the issue is resovled.
Bumps vite-plus from 0.1.13 to 0.1.17.
Release notes
Sourced from vite-plus's releases.
... (truncated)
Commits
48e49cafeat(deps): upgrade upstream dependencies (#1375)eb7370afeat(cli): add vp node shorthand for vp env exec node (#1359)4d9bc46feat(js-executor): block vp commands when Node.js version is incompatible (#1...bd0e949fix(cli,bin): Addenv.VP_VERSIONfor oxlint and oxfmt (#946)18f9f50refactor: split cli.rs into focused submodules (#1351)6ebba00refactor: extract check command into its own module (#1350)e22fc93feat(create): set npm.scriptRunner to vp invp create(#1346)31e90b9refactor(cli): use rolldown'sdisable_panic_hookfeature for panic hook (#1...5ab336ffix: more safer Vite+ global install andvp upgrade(#1338)51def64fix: Consolidate agent instructions. (#1340)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.