Skip to content

hydrogen upgrade detects the wrong package manager in monorepos and runs npm inside pnpm/yarn/bun workspaces #3793

Description

@JohnCashmore

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

  1. 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
    
  2. Pin the app to an older Hydrogen version (so an upgrade is available), run pnpm install from the workspace root, and commit everything.

  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions