`corepack use` in monorepo targets root not project package.json
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 45/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- À l'abandon
- Stack technique
- node.js, typescript
Piste de recherche
Commencez par l’implémentation de la commande corepack use et reproduisez le comportement avec les commandes indiquées dans l’issue depuis un répertoire de projet imbriqué. Suivez la manière dont les fichiers package.json sont trouvés et dont le fichier à modifier et à utiliser pour l’installation est sélectionné. Le travail est terminé lorsque le package.json du projet imbriqué est créé ou mis à jour sans modifier le package.json racine du dépôt, la reproduction confirmant le résultat.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
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 [email protected]
git status
package.json in the root of the repo has been modified (not examples/yarn-classic/package.json) with the addition of
"packageManager": "[email protected]+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 [email protected]
Installing [email protected] in the project...
corepack Installing [email protected] 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 [email protected] 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...
- Langage dominant
- TypeScript
- Étoiles
- 3.8k
- Forks
- 282
- Merge moyen
- 3 h 21 min
- PR mergées (30 j)
- 1
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de nodejs/corepack
-
Difficulté 2/5 1-3 heures Accessibilité débutants 64/100
-
[BUG] corepack not use COREPACK_NPM_REGISTRY install of tarballPeut-être pris @Yash121l l’a pris il y a 27 jours. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
-
`Cannot find module .../bin/pnpm.cjs` after upgrading from Corepack <=0.34.4 with pnpm 12 cachedPeut-être pris @abappi19 l’a pris il y a 6 jours. Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 75/100
-
Support signature verification against a custom COREPACK_NPM_REGISTRYPeut-être pris Une pull request liée à cette issue est ouverte ou déjà fusionnée. Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 68/100
-
Error when upgrading pnpm to latest in `devEngines.packageManager`Peut-être pris @thiagobarbosa l’a pris il y a 77 jours. Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 52/100
Toutes les issues de nodejs/corepack
Issues similaires
-
cleanName keeps a state code that's joined to the word before it (SavannahGa → "Savannah Ga")Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
openwatersio/slackwater-database#281 ·
Les mainteneurs répondent en général sous 1 jour
-
accepted bug via-triage
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
pingdotgg/t3code#18690 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Bayern feature:Application ready web
Difficulté 2/5 1-3 heures Accessibilité débutants 67/100
digitalfabrik/entitlementcard#3176 ·
Les mainteneurs répondent en général sous 7 jours
-
[BUG] 运行位置的分支列表不自动刷新,外部新建的分支看不到Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
NanmiCoder/cc-haha#1533 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
Les mainteneurs répondent en général sous 1 jour