CLI build and tests fail when the repo is cloned to a path containing spaces

[AryanKansagara]

Which package or tool is having this issue?

CLI

What version of that package or tool are you using?

main @ b543c6d (@shopify/cli-hydrogen 13.0.4)

Steps to Reproduce

Clone the repo into a directory whose path contains a space, then build:

git clone https://github.com/Shopify/hydrogen.git "/tmp/Open Source/hydrogen"
cd "/tmp/Open Source/hydrogen"
pnpm install
pnpm --dir packages/cli build

Expected Behavior

The build succeeds, the same as it does from a path without spaces.

Actual Behavior

The build fails:

Error: Trying to use skeleton source dir outside of Hydrogen monorepo.
    at getSkeletonSourceDir (packages/cli/tsup.config.bundled_*.mjs:36:11)
    at Object.onSuccess (packages/cli/tsup.config.bundled_*.mjs:166:18)

pnpm --dir packages/cli test fails as well, with 11 failed test files and 39 failed tests on the same checkout.

Cause is in packages/cli/src/lib/build.ts:

const monorepoPackagesPath = new URL('../../..', import.meta.url).pathname;

URL.pathname is percent-encoded, so a checkout at /Users/me/Open Source/hydrogen yields /Users/me/Open%20Source/hydrogen/packages/. That path does not exist on disk, so the existsSync check for templates/skeleton fails, isHydrogenMonorepo is false, and getSkeletonSourceDir() throws.

The error message points at the monorepo layout rather than the directory name, so the actual cause is not obvious. The fix is to decode the pathname before use.

Confirmed on the same machine by toggling only that one expression:

	packages/cli build	packages/cli tests
Current main	fails	11 files / 39 tests failed
With the pathname decoded	succeeds	57 files / 434 tests passed

Note that packages/hydrogen/src/vite/plugin.ts uses the same new URL(...).pathname pattern, but is not affected, because it only checks endsWith('/packages/') and any encoded segment appears earlier in the path.

This only affects working in the monorepo. Installed npm packages are unaffected, since isHydrogenMonorepo is false there either way.

I have a fix ready and will open a PR shortly.

[AryanKansagara]

Opened the PR. Please let me know if you have any feedback or if any changes are needed. Thanks !

[AryanKansagara]

The comment above this line points at #3074. git log -L on it confirms detection used to be an endsWith string check, which ignored the encoded part of the path. #3074 swapped it for an existsSync check, which is when the encoding started to matter. So the bad line is old, it just became load-bearing then.