Repository navigation
corepack use in monorepo targets root not project package.json #607
Description
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 statuspackage.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...
Activity
arcanis commentedon Jan 21, 2025
We're missing a test on that, but if I remember correctly the intent is to update the closest package.json that contains a
packageManagerfield, or the closest package.json otherwise.MikeMcC399 commentedon Jan 21, 2025
MikeMcC399 commentedon Jan 23, 2025
@arcanis
I went back and looked at the different cases. I think if
corepack useis 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 apackage.jsonif it is missing. So there would be scope for enhancing the documentation and for making the working ofcorepack usein a monorepo consistent any usable.package.jsonin projectpackageManagerin projectpackage.jsoncorepack usein projectpackage.jsonpackage.jsonpackage.jsonarcanis commentedon Jan 23, 2025
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?
MikeMcC399 commentedon Jan 23, 2025
@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 usein the Yarn Classic project directory, I don't want it to write into the root npm directory. I want it to update thepackage.jsoninexamples/yarn-classic.I can probably work around this by creating an initial
packageManagerrecord by hand in the projectpackage.jsonwhere I want it to be.arcanis commentedon Jan 23, 2025
I see - yes, adding an explicit
packageManagerwould be my current recommendation. We perhaps could also have a--hereflag, or similar, for special cases where the user really wants to nest projects into one another.MikeMcC399 commentedon Jan 24, 2025
@arcanis
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.jsonsuch as a--hereflag (overriding any search algorithm) would solve this.I have split out the documentation issue and put it in #610.
Aschenbath commentedon Oct 19, 2026