fix(cli): replace preferred-pm with local implementation

[binoy14]

Description

Replaces the preferred-pm npm dependency with a local implementation to fix compatibility with yarn v1 on Node 20. The preferred-pm@5.0.0 package requires node >=22.13, which breaks yarn v1 Classic since it enforces engine checks by default.

See #983 for context on the yarn v1 + Node 20 incompatibility.

Changes:

• Remove preferred-pm dependency from @sanity/cli
• Add local preferredPm module that detects package managers via lock files, workspace configurations, and node_modules markers
• Convert from async to sync detection (no behavioral change — the original library only did sync filesystem checks behind an async API)
• Fix workspace detection for paths nested inside a package (e.g. packages/child/src)
• Fix .modules.yaml parsing to handle both YAML and JSON formats

What to review

• packages/@sanity/cli/src/util/packageManager/preferredPm.ts — the local implementation
• packages/@sanity/cli/src/util/packageManager/__tests__/preferredPm.test.ts — unit tests (22 cases)
• packages/@sanity/cli/src/util/packageManager/packageManagerChoice.ts — updated import and usage

Testing

Unit tests cover: lock file detection (all 6 lock file types), parent directory pnpm-lock walk-up, workspace root detection (yarn/npm/pnpm/bun workspaces, subdirectory paths, non-matching paths, workspaces.packages format), node_modules marker detection (YAML and JSON .modules.yaml formats), and empty directory fallback.

pnpm test packages/@sanity/cli/src/util/packageManager/__tests__/preferredPm.test.ts

---

Note

Medium Risk
Changes CLI package-manager auto-detection logic and removes a third-party dependency, which can affect dependency installation/upgrade flows across different workspace layouts. Risk is mitigated by extensive new unit tests, but behavior differences in edge cases are still possible.

Overview
Fixes Yarn v1 on Node 20 by removing the preferred-pm dependency (and its Node 22+ engine requirement) and switching getPackageManagerChoice to use a new in-repo preferredPm implementation.

The new detector infers the preferred package manager from lockfiles, pnpm lock/workspace files in parent directories, workspace root package.json globs, and node_modules markers (including more tolerant .modules.yaml parsing), with a comprehensive new vitest suite to cover these cases.

^{Reviewed by Cursor Bugbot for commit a000164. Bugbot is set up for automated code reviews on this repo. Configure here.}

[claude]

Claude finished @binoy14's task in 5m 10s —— View job

---

Review

• Read changed files
• Analyze implementation for bugs/logic errors
• Check test coverage
• Verify changeset

---

Previously reported infinite loop (b809ca7) is fixed — the current HEAD has no continue in detectFromWorkspaceRoot, so dir always advances. ✓

preferredPm.ts:83 — ?? 'yarn' fallback assumes workspaces implies yarn

return detectFromLockFile(dir) ?? 'yarn'

Any directory with a workspaces field and no lock file returns 'yarn', even for npm workspaces. npm has supported workspaces since v7. A fresh checkout of an npm monorepo (before npm install is run) will be incorrectly detected as yarn. This is inherited from the original preferred-pm behavior, but it's worth knowing it exists. Fix this →

preferredPm.ts:66-95 — matchDir logic is correct but opaque

The packageDir === dir ? resolvedPkgPath : packageDir branch serves two different purposes:

• When dir === resolvedPkgPath === packageDir (starting path is a package root): relativePath === '' triggers an immediate match — correct for workspace roots.
• When findNearestPackageDir returns the workspace root itself (no intermediate package.json): the raw resolvedPkgPath is used for glob matching rather than packageDir.

Both paths work correctly for all test cases but the intent is non-obvious. A comment on that line would help future readers.

preferredPm.ts:54-64 — findNearestPackageDir never checks filesystem root

while (dir !== root) { ... }
return startDir

The loop exits before checking root/package.json. In practice this is fine, but it's inconsistent with findUp which does check root. Not a real bug.

Test coverage is thorough — 22 cases including the nested workspace walk-up, malformed JSON, YAML/JSON .modules.yaml parsing, and permission errors. The malformed package.json test requested in review is present at line 139. ✓

Changeset — patch bump is correct. Summary "Fix package manager detection failing with yarn v1 on Node 20." is concise and user-facing. ✓

picomatch is already a direct dependency at ^4.0.4 — no new dep introduced. ✓

[github-actions]

📦 Bundle Stats — @sanity/cli

Compared against main (39834eef)

@sanity/cli

Metric	Value	vs main (39834ee)
Internal (raw)	2.1 KB	-
Internal (gzip)	799 B	-
Bundled (raw)	10.94 MB	-
Bundled (gzip)	2.05 MB	-
Import time	870ms	+16ms, +1.9%

bin:sanity

Metric	Value	vs main (39834ee)
Internal (raw)	975 B	-
Internal (gzip)	460 B	-
Bundled (raw)	9.84 MB	-
Bundled (gzip)	1.77 MB	-
Import time	2.05s	+56ms, +2.8%

🗺️ View treemap · Artifacts

Details

• Import time regressions over 10% are flagged with ⚠️
• Sizes shown as raw / gzip 🗜️. Internal bytes = own code only. Total bytes = with all dependencies. Import time = Node.js cold-start median.

📦 Bundle Stats — @sanity/cli-core

Compared against main (39834eef)

Metric	Value	vs main (39834ee)
Internal (raw)	93.8 KB	-
Internal (gzip)	21.9 KB	-
Bundled (raw)	21.62 MB	-
Bundled (gzip)	3.42 MB	-
Import time	823ms	+10ms, +1.3%

🗺️ View treemap · Artifacts

Details

• Import time regressions over 10% are flagged with ⚠️
• Sizes shown as raw / gzip 🗜️. Internal bytes = own code only. Total bytes = with all dependencies. Import time = Node.js cold-start median.

📦 Bundle Stats — create-sanity

Compared against main (39834eef)

Metric	Value	vs main (39834ee)
Internal (raw)	976 B	-
Internal (gzip)	507 B	-
Bundled (raw)	50.7 KB	-
Bundled (gzip)	12.6 KB	-
Import time	❌ ChildProcess denied: node	-

Details

• Import time regressions over 10% are flagged with ⚠️
• Sizes shown as raw / gzip 🗜️. Internal bytes = own code only. Total bytes = with all dependencies. Import time = Node.js cold-start median.

[github-actions]

Coverage Delta

File	Statements
packages/@sanity/cli/src/util/packageManager/packageManagerChoice.ts	42.9% (±0%)
packages/@sanity/cli/src/util/packageManager/preferredPm.ts	93.0% (new)

Comparing 2 changed files against main @ 2fd358fc52ed3e2c3b89e45796e4a6044e03cd4c

Overall Coverage

Metric	Coverage
Statements	84.0% (+ 0.1%)
Branches	73.8% (+ 0.1%)
Functions	84.0% (+ 0.1%)
Lines	84.5% (+ 0.1%)

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b809ca7. Configure here.}

[mttdnt]

LGTM, seems close enough to the npm packages, just a couple nits

[mttdnt]

should this be in a separate types file just to avoid the circular import

[mttdnt]

In this block maybe add a test for a malformed package.json in detectFromWorkspaceRoot