Skip to content

vp treats a nested project as part of the parent's pnpm workspace, ignoring its own packageManager and lockfile #3013

Open
voidzero-dev/vite-task
#859

Description

@Goobles

Describe the bug

In a repo whose root is a pnpm project with a settings-only pnpm-workspace.yaml (no packages, used for overrides / allowBuilds), vp treats every nested project as part of that workspace, even when the nested folder isn't listed under packages and has its own packageManager pin and lockfile.

Inside the nested npm project svc/:

  • vpr hello runs the root's hello script instead of svc's.
  • vp install --frozen-lockfile runs pnpm, which refuses with This project is configured to use npm. Without a packageManager field in svc/ it fails with Headless installation requires a pnpm-lock.yaml file instead.
  • vp env current inside svc/ reports pnpm 12.11.2 with source packageManager, the root's pin, not svc's npm@11.17.0.

I expected vp to treat svc/ as its own npm project, as it does when the root has no pnpm-workspace.yaml. pnpm 11+ only reads settings like overrides from pnpm-workspace.yaml, so a pnpm root can't avoid having one.

We hit this when switching a repo root to pnpm: about 20 Cloud Run services below it stay on npm or bun, and vp stopped working in all of them.

Workaround: a comment-only pnpm-workspace.yaml plus the packageManager pin in each nested project makes vp treat it as its own project again.

Reproduction

https://github.com/Goobles/vp-nested-workspace-repro

Steps to reproduce

git clone https://github.com/Goobles/vp-nested-workspace-repro
cd vp-nested-workspace-repro
./repro.sh

repro.sh runs vpr hello and vp install --frozen-lockfile in svc/, first with the root pnpm-workspace.yaml (bug), then with it moved away (expected behaviour).

System Info

# vp env current (run inside svc/)
Node.js:
  Version    24.19.0
  Source     default
  Bin Path   /home/agent/.vite-plus/js_runtime/node/24.19.0/bin/node
  Installed  true
  Mode       managed

Package Manager:
  Name       pnpm
  Version    12.11.2
  Source     packageManager
  Bin Paths
    pnpm     /home/agent/.vite-plus/package_manager/pnpm/12.11.2/pnpm/bin/pnpm
    pnpx     /home/agent/.vite-plus/package_manager/pnpm/12.11.2/pnpm/bin/pnpx
  Installed  true
  Mode       system_first

# vp --version
vp v1.1.0

# Linux x86_64

Used Package Manager

npm (nested project), pnpm (repo root)

Logs

### 1. Parent has pnpm-workspace.yaml (bug)
$ vpr hello
$ echo hello from ROOT ⊘ cache disabled
hello from ROOT

$ vp install --frozen-lockfile
  × This project is configured to use npm
  help: Run a one-off command with "pnpm dlx npm <command>", or link a npm
        command that follows this project's pin with "pnpm shim add npm".

### 2. Parent pnpm-workspace.yaml removed (expected behaviour)
$ vpr hello
$ echo hello from SVC ⊘ cache disabled
hello from SVC

$ vp install --frozen-lockfile
added 1 package, and audited 2 packages in 390ms
found 0 vulnerabilities

Validations

Written by claude-opus-5-5 via Claude Code in T3 Code on goobles-agentbox.

Activity

  1. self-assigned this
    on Oct 12, 2026
  2. liangmiQwQ commented on Oct 12, 2026

    @liangmiQwQ
    Collaborator

    Thanks for reporting. The current Vite+ always treats workspace-root's package manager declaration as the source of truth, just like what you said.

    I took a look at corepack, pnpm and @antfu/ni's behavior, and I think this makes sense since they'll all find the nearest package.json, use their own declared packageManager, instead of Vite+'s find workspace root.

    This requires us to modify the detecting logic and change vp <package-manager commands> and <pnpm/bun... shims>'s behavior. cc @fengmk2

  3. liangmiQwQ commented on Oct 14, 2026

    @liangmiQwQ
  4. fengmk2 commented on Oct 16, 2026

    @fengmk2
    Member

    Since svc/ is not included in the workspace packages, this looks like a workspace detection bug. Running vp install from the root should use the root configuration, but running it inside an independent nested project should respect that project's configuration.

    We should fix workspace membership detection without changing the existing behavior for actual workspace members. -C changes the working directory, but it does not resolve this particular issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingenhancementNew feature or request

Type

No type

Fields

Priority

None yet

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions