fix(install_node_modules): detect package manager from workspace root

[PHILLIPS71]

Why

In pnpm and bun monorepos, eas/install_node_modules incorrectly falls back to yarn even when a pnpm-lock.yaml exists at the workspace root.

resolvePackageManager is called with the app's working directory (apps/app) before findPackagerRootDir has located the workspace root. Since @expo/package-manager detects the package manager via lockfiles, and the lockfile lives at the monorepo root rather than the app subdirectory, no package manager is detected and the function defaults to yarn. findPackagerRootDir then correctly resolves the monorepo root, but by that point yarn has already been chosen and is invoked from there.

The obvious workaround of adding a packageManager field to the app's own package.json does not work because resolvePackageManager does not read this field. Yarn is still invoked and then errors when it encounters the field value:

Running "yarn install --frozen-lockfile --production false" in /Users/expo/workingdir/build directory
error This project's package.json defines "packageManager": "yarn@pnpm@10.33.0". However the current global version of Yarn is 1.22.22.
Presence of the "packageManager" field indicates that the project is meant to be used with Corepack, a tool included by default with all official Node.js distributions starting from 16.9 and 14.19.
Corepack must currently be enabled by running corepack enable in your terminal. For more information, check out https://yarnpkg.com/corepack.
yarn install --frozen-lockfile --production false exited with non-zero code: 1

The only working solution today is a custom build workflow that replaces eas/install_node_modules entirely.

How

Swap the order of resolvePackageManager and findPackagerRootDir so the package manager is detected from the workspace root, where the lockfile actually lives.

If no workspace root is found, findPackagerRootDir returns the working directory unchanged, so behaviour for non-monorepo projects is identical.

Test Plan

Reproduction:

1. Create a pnpm monorepo with pnpm-workspace.yaml and pnpm-lock.yaml at the root
2. Place an Expo app in a subdirectory (e.g. apps/app) without its own lockfile
3. Run eas build and observe EAS invoking yarn install

After the fix:

• findPackagerRootDir resolves the monorepo root
• resolvePackageManager finds pnpm-lock.yaml there and correctly selects pnpm
• pnpm install --frozen-lockfile runs from the monorepo root and succeeds

[github-actions]

Subscribed to pull request

File Patterns	Mentions
**/*	@douglowder

Generated by CodeMention