`corepack use` in monorepo targets root not project package.json

[MikeMcC399]

Current behavior

In a monorepo if corepack use is executed in a project directory, which is a sub-directory of a monorepo root directory containing an existing package.json, it does not create or update the package.json in the project directory. Instead it makes changes to the package.json in the root of the monorepo.

The monorepo is not a workspace. Each project is separate.

Expected behavior

If corepack use is executed in a monorepo project directory, it should operate on or create a package.json in that directory not in the root directory of the monorepo.

The corepack README does not discuss how corepack use is supposed to behave in a hierarchy of directories containing their own package.json files. It says simply:

When run, this command will retrieve the latest release matching the provided descriptor, assign it to the project's package.json file, and automatically perform an install.

The Node.js documentation for corepack Configuring a package says:

The Corepack proxies will find the closest package.json file in your current directory hierarchy to extract its "packageManager" property.

I would understand this to mean that if there is a package.json in the current working directory, then corepack use should act on this package.json, and not search up the hierarchy to change a higher level package.json

Step to reproduce

Ubuntu 24.04.1 LTS, Node.js 22.13.0 LTS, Corepack 0.30.0

rm -rf ~/.cache/node/corepack
corepack enable yarn

git clone https://github.com/cypress-io/github-action
cd github-action
git clean -xfd # if repeating
cd examples/yarn-classic
corepack use yarn@1.22.22
git status

package.json in the root of the repo has been modified (not examples/yarn-classic/package.json) with the addition of

"packageManager": "yarn@1.22.22+sha512.a6b2f7906b721bba3d67d4aff083df04dad64c399707841b7acf00f6b133b7ac24255f2652fa22ae3534329dc6180534e98d17432037ff6fd140556e2bb3137e"

yarn install has been run in examples/yarn-classic, creating a new examples/yarn-classic/node_modules directory there.

Logs

The debug logs do not show which directory is being used to write a package.json file, nor which directory yarn install is being run in:

$ corepack use yarn@1.22.22
Installing yarn@1.22.22 in the project...
  corepack Installing yarn@1.22.22 from https://registry.yarnpkg.com/yarn/-/yarn-1.22.22.tgz +0ms
  corepack Downloading to /home/mike/.cache/node/corepack/v1/corepack-5003-f7268cee.b6ed3 +1ms
  corepack LastKnownGood file would be located at /home/mike/.cache/node/corepack/lastKnownGood.json +802ms
  corepack No LastKnownGood version found in Corepack home. +0ms
  corepack Download and install of yarn@1.22.22 is finished +0ms
  corepack Checking /home/mike/github/cypress-io/github-action/examples/yarn-classic/package.json +1ms
  corepack Checking /home/mike/github/cypress-io/github-action/examples/package.json +0ms
  corepack Checking /home/mike/github/cypress-io/github-action/package.json +0ms
  corepack Checking /home/mike/github/cypress-io/package.json +1ms
  corepack Checking /home/mike/github/package.json +0ms
  corepack Checking /home/mike/package.json +0ms
  corepack Checking /home/package.json +0ms
  corepack Checking /package.json +0ms

yarn install v1.22.22
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...

[arcanis]

We're missing a test on that, but if I remember correctly the intent is to update the closest package.json that contains a packageManager field, or the closest package.json otherwise.

[MikeMcC399]

@arcanis

... if I remember correctly the intent is to update the closest package.json that contains a packageManager field, or the closest package.json otherwise.

That would make sense to me and it would be my preferred way of working!

[MikeMcC399]

@arcanis

We're missing a test on that, but if I remember correctly the intent is to update the closest package.json that contains a packageManager field, or the closest package.json otherwise.

I went back and looked at the different cases. I think if corepack use is executed in a project directory, not the root directory, of a monorepo, it should always act in that directory. There are however gaps in the documentation concerning what the target directory for its actions are supposed to be, and if it is supposed to create a package.json if it is missing. So there would be scope for enhancing the documentation and for making the working of corepack use in a monorepo consistent any usable.

package.json in project	packageManager in project package.json	corepack use in project	correct?
does not exist	-	updates root package.json	❓
exists	not present	updates root package.json	❌
exists	present and valid	updates project package.json	✅

[arcanis]

I'm not sure I follow - the test case below seems to return the expected results (it updates the monorepo root, not the workspace directory). Do you get something else?

cd $(mktemp -d)
yarn init -2 -w
mkdir -p packages/foo
echo '{}' > packages/foo/package.json
jq .packageManager package.json
(cd packages/foo && corepack use yarn@4.5.0)
jq .packageManager package.json

[MikeMcC399]

@arcanis

I ran your example and the result is that it updates the monorepo root as you say. Your example is however a pure Yarn repo with workspaces where that behavior is probably desirable.

The repo I am dealing with is https://github.com/cypress-io/github-action and that is a mixed npm, Yarn Classic, Yarn Modern, pnpm repo which demonstrates how to use Cypress in GitHub Actions with these different types of mainstream package managers and some different application frameworks. It also includes workspaces for both Yarn Classic and pnpm in projects in the hierarchy. I expect it will be one of the most complex setups in this regard.

In this repo, if I execute corepack use in the Yarn Classic project directory, I don't want it to write into the root npm directory. I want it to update the package.json in examples/yarn-classic.

I can probably work around this by creating an initial packageManager record by hand in the project package.json where I want it to be.

[arcanis]

I see - yes, adding an explicit packageManager would be my current recommendation. We perhaps could also have a --here flag, or similar, for special cases where the user really wants to nest projects into one another.

[MikeMcC399]

@arcanis

I see - yes, adding an explicit packageManager would be my current recommendation. We perhaps could also have a --here flag, or similar, for special cases where the user really wants to nest projects into one another.

I will take a look at writing and submitting a separate user story for the special case as this would be a feature request. Having an option to determine the target location for package.json such as a --here flag (overriding any search algorithm) would solve this.

I have split out the documentation issue and put it in #610.