What is the location of your example repository?
n/a — reproduction steps below create one from scratch.
Which package or tool is having this issue?
CLI
What version of that package or tool are you using?
@shopify/cli-hydrogen 12.0.1 (also reproducible on earlier versions)
Steps to Reproduce
-
Create a pnpm workspace with a Hydrogen app as a workspace member:
my-monorepo/
├── pnpm-workspace.yaml # packages: ['apps/*']
├── pnpm-lock.yaml # single lockfile at the workspace root
└── apps/
└── storefront/ # Hydrogen app (no lockfile in here)
└── package.json
-
Pin the app to an older Hydrogen version (so an upgrade is available), run pnpm install from the workspace root, and commit everything.
-
From apps/storefront, run shopify hydrogen upgrade and select a newer version.
Expected Behavior
The CLI detects that the project is a pnpm workspace (lockfile at the workspace root) and runs the upgrade with pnpm (pnpm add …), updating the root pnpm-lock.yaml.
Actual Behavior
Package manager detection only looks for a lockfile in the app directory itself. In a monorepo the lockfile lives at the workspace root, so detection finds nothing and falls back to npm. The upgrade then runs npm install --legacy-peer-deps inside the pnpm workspace, which fails on workspace: protocol dependencies (and in partial-failure cases leaves a stray package-lock.json in the app directory). The "Undo these upgrades?" instructions at the end also print npm i instead of pnpm i.
The same applies to yarn and bun workspaces — any setup where the lockfile is in an ancestor directory of the app.
Root cause: upgrade.ts uses cli-kit's getPackageManager(appPath), which checks only that single directory for yarn.lock/pnpm-lock.yaml/bun.lockb before falling back to npm — it never walks up to the workspace root.
I have a fix ready and will open a PR shortly.
What is the location of your example repository?
n/a — reproduction steps below create one from scratch.
Which package or tool is having this issue?
CLI
What version of that package or tool are you using?
@shopify/cli-hydrogen 12.0.1 (also reproducible on earlier versions)
Steps to Reproduce
Create a pnpm workspace with a Hydrogen app as a workspace member:
Pin the app to an older Hydrogen version (so an upgrade is available), run
pnpm installfrom the workspace root, and commit everything.From
apps/storefront, runshopify hydrogen upgradeand select a newer version.Expected Behavior
The CLI detects that the project is a pnpm workspace (lockfile at the workspace root) and runs the upgrade with pnpm (
pnpm add …), updating the rootpnpm-lock.yaml.Actual Behavior
Package manager detection only looks for a lockfile in the app directory itself. In a monorepo the lockfile lives at the workspace root, so detection finds nothing and falls back to npm. The upgrade then runs
npm install --legacy-peer-depsinside the pnpm workspace, which fails onworkspace:protocol dependencies (and in partial-failure cases leaves a straypackage-lock.jsonin the app directory). The "Undo these upgrades?" instructions at the end also printnpm iinstead ofpnpm i.The same applies to yarn and bun workspaces — any setup where the lockfile is in an ancestor directory of the app.
Root cause:
upgrade.tsuses cli-kit'sgetPackageManager(appPath), which checks only that single directory foryarn.lock/pnpm-lock.yaml/bun.lockbbefore falling back to npm — it never walks up to the workspace root.I have a fix ready and will open a PR shortly.