Closed hangya-fadir closed 1 month ago
You need to enable Corepack by running corepack enable
before running yarn commands. See https://yarnpkg.com/corepack for more information
yarn set version classic
started pointing to 4.2.2, which is a breaking change, most likely a bug.
Even if I start out with Yarn 1.22.19
installed and corepack
not enabled, I still run into this issue:
$ corepack disable
$ npm install yarn@1.22.19 --global
$ yarn set version stable
➤ YN0000: You don't seem to have Corepack enabled; we'll have to rely on yarnPath instead
➤ YN0000: Downloading https://repo.yarnpkg.com/4.2.2/packages/yarnpkg-cli/bin/yarn.js
➤ YN0000: Saving the new release in .yarn/releases/yarn-4.2.2.cjs
➤ YN0000: Done with warnings in 0s 289ms
$ yarn set version classic
➤ YN0000: Downloading https://classic.yarnpkg.com/latest.js
➤ YN0000: Saving the new release in .yarn/releases/yarn-classic.cjs
➤ YN0000: Done in 2s 497ms
$ yarn set version stable
error This project's package.json defines "packageManager": "yarn@4.2.2". 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.
Enabling corepack
will work around this issue, however considering that corepack
is still classified as experimental, it is problematic to force its use in a production environment.
yarn set version classic
started pointing to 4.2.2, which is a breaking change, most likely a bug.
It didn't. If you have an issue, please open a separate issue with a reproduction.
❯ yarn init -2
➤ YN0000: · Yarn 4.2.2
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0000: └ Completed
➤ YN0000: · Done in 0s 27ms
❯ yarn set version classic
➤ YN0000: Downloading https://classic.yarnpkg.com/latest.js
➤ YN0000: Saving the new release in .yarn/releases/yarn-classic.cjs
➤ YN0000: Done in 1s 530ms
❯ yarn --version
1.22.22
in case the global yarn version is 1.22.21 i can't switch to yarn 4.2.2 if the package.json already contains "packageManager": "yarn@4.2.2"
As mentioned in the error message, if the package contains a packageManager
field, then you're expected to use Corepack. You can use also define SKIP_YARN_COREPACK_CHECK=1
as a workaround.
Enabling corepack will work around this issue, however considering that corepack is still classified as experimental, it is problematic to force its use in a production environment.
If the project contains packageManager
, it's that it's meant to use Corepack. If you don't want to force its use on an environment, don't add the packageManager
field (or use the environment variable suggested above).
@arcanis
Thanks for the workaround SKIP_YARN_COREPACK_CHECK=1
!
It appears that this issue is caused by the CLI command
yarn set version classic
I would expect this command to remove
{
"packageManager": "yarn@4.2.2"
}
from package.json
. This entry was put there by the previous command
yarn set version stable
Or is it expected that yarn set version classic
would leave the entry for yarn@4.2.2
in package.json
?
https://github.com/yarnpkg/berry/issues/6310#issuecomment-2132904285 (marked as off-topic)
Well something broke our CI today, and it's these lines that returned a different output than before
Run rm -rf package.json yarn.lock
rm -rf package.json yarn.lock
yarn set version classic
yarn add axios@0.27.2 danger@11.1.4 typescript@4.8.2 glob@7.1.7
shell: /usr/bin/bash -e {0}
➤ YN0000: Downloading https://classic.yarnpkg.com/latest.js
➤ YN0000: Saving the new release in .yarn/releases/yarn-classic.cjs
➤ YN0000: Done in 0s 626ms
error This project's package.json defines "packageManager": "yarn@4.2.2". However the current global version of Yarn is 1.22.22.
As you can see, we used to delete the whole package.json
, but we've never seen the error before. And we run this for over a year now. That's why I believe something must have changed on Yarn's side very recently. We changed the classic
to 1.22.22
and it works now.
Or is it expected that yarn set version classic would leave the entry for yarn@4.2.2 in package.json?
Yarn Classic does the check before spawning any Yarn command - including set version
. Changing that would require adding more spaghetti code into the Classic CLI bootstrap; I'd really prefer to avoid that.
This, or something that presents the same, started hitting us as well (in addition to the other issue I opened that's referenced earlier in this comment chain).
Packing ember-ajax-fetch@https://github.com/expel-io/ember-ajax-fetch.git#commit=0341a43f615f54a5e6d448eb19392c54aefb262d from sources
Using Yarn Classic for bootstrap. Reason: "__metadata" key not found in yarn.lock, must be a Yarn classic lockfile
➤ YN0000: Downloading https://classic.yarnpkg.com/latest.js
➤ YN0000: Saving the new release in .yarn/releases/yarn-classic.cjs
➤ YN0000: Done in 1s 128ms
error This project's package.json defines "packageManager": "yarn@4.2.2". 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.
The odd thing is that we are using corepack. Even if I run corepack enable
explicitly before running yarn
(just to be absolutely certain of that claim), packing packages from source fails. Before the recent updates to the 1.22.22 version, we weren't seeing this issue. Nothing in our environment or Yarn config has changed. If I run yarn set version 1.22.22
, and use Yarn Classic for the build, things work again, but I think that's expected based on how these packages are handled by 1.x.
An interesting thing to note is that running yarn set version 1.22.22
works as expected and sets the global version to 1.22.22
, but if I subsequently run yarn set version 4.2.2
, I see the exact error that's being output during packing:
error This project's package.json defines "packageManager": "yarn@4.2.2". 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.
Editing with new info:
Our issue seems to have been that running yarn set version [version]
creates a package.json
and .yarnrc.yml
file wherever it's run, regardless of whether that location is a Yarn project. We ran it in the parent directory of our project to set the global Yarn version as part of a previous set of commands, but there was a mismatch between the created package.json
value of packageManager
and the value specified by our actual project's package.json
. Once we deleted this (erroneously created?) package.json
, we were able to switch versions again in the project, which allowed the builds from source to work as well.
Self-service
Describe the bug
in case the global yarn version is 1.22.21 i can't switch to yarn 4.2.2 if the package.json already contains "packageManager": "yarn@4.2.2"
NOTE: this is used in Ci/CD pipeline, e.g no way to leave the project folder
To reproduce
Environment
Additional context
also the
yarn dlx -q envinfo --preset jest
is not working in the above case