Avoid circular binding resolution between vite-plus-core and vite-plus

[jong-kyung]

Context

While investigating a pnpm enable-global-virtual-store issue, @voidzero-dev/vite-plus-core failed to resolve vite-plus/binding when executed from pnpm's global virtual store realpath.

Current release rewrite:

@rolldown/binding-* -> vite-plus/binding

This creates an awkward package relationship:

vite-plus -> @voidzero-dev/vite-plus-core -> vite-plus/binding

A proposed optional peer dependency workaround(#2053) makes the dependency explicit, but it still feels circular because vite-plus already depends on @voidzero-dev/vite-plus-core .

Reproduction

A minimal reproduction is available here:

https://github.com/jong-kyung/repro-vite-plus-2054

It was created with vp create vite:application and enables pnpm's global virtual store. Running the repro imports vite/rolldown, which resolves @voidzero-dev/vite-plus-core from pnpm's global store realpath and fails to resolve vite-plus/binding.

vp install
vpr repro 
# or
pnpm run repro

Expected failure:

Cannot find module 'vite-plus/binding'

Proposal

Consider moving the binding resolver into a neutral package, for example:

@voidzero-dev/vite-plus-binding

Then both packages can depend on it:

vite-plus -> @voidzero-dev/vite-plus-binding
@voidzero-dev/vite-plus-core -> @voidzero-dev/vite-plus-binding

and the release rewrite can become:

@rolldown/binding-* -> @voidzero-dev/vite-plus-binding

vite-plus/binding could remain as a compatibility re-export.

Benefit

This avoids the circular vite-plus -> core -> vite-plus/binding shape while making native binding resolution explicit for pnpm global virtual store layouts.

[jong-kyung]

@fengmk2 When you have time, could you take a look and share any preference on the direction or implementation approach?

[fengmk2]

Could you provide a minimal reproduction repo first? I'd like to reproduce the issue first, then check the pnpm documentation.

[jong-kyung]

Sure, I added a minimal reproduction repo to the issue description:
https://github.com/jong-kyung/repro-vite-plus-2054

[fengmk2]

Thanks for the repro, I can reproduce it. Your diagnosis is right: core requires vite-plus/binding without declaring vite-plus, so it only resolves through pnpm's hidden hoist, and the global virtual store (like Yarn PnP) enforces declared dependencies.

A neutral @voidzero-dev/vite-plus-binding package would work, but I'd prefer fixing it with the packages we already publish instead of adding a new lockstep-published one:

1. Rewrite per-platform: @rolldown/binding-<platform> -> @voidzero-dev/vite-plus-<platform> (same napi-rs platform suffixes).
2. Have packages/core/build.ts add those platform packages to core's own optionalDependencies (generated from napi.targets, like vite-plus already does).

Core then only requires what it declares, which works under the global virtual store, Yarn PnP, npm, and bun. The vite-plus/binding export stays for compatibility.

Bonus: the current collapsed rewrite turns the loader's version-check requires into require('vite-plus/binding/package.json'), which throws ERR_PACKAGE_PATH_NOT_EXPORTED, so every per-platform branch fails and the binding only loads via the rewritten WASI-fallback branch. The per-platform rewrite fixes that too (platform packages have no exports map), making the intended load path and version check work again. Verified both locally by simulating the global-virtual-store layout with the published 0.2.2 tarballs.

[fengmk2]

cc @Brooooooklyn

[jong-kyung]

Thanks for the detailed explanation and verification.
Would it be okay if I work on the fix in the direction you suggested and open a PR?