berry: [Bug] "YN0028: The lockfile would have been created by this install, which is explicitly forbidden", but `yarn.lock` exists and is not modified when running `yarn install` locally

For people still experiencing this today with >=yarn@3.3.1, your issue could be caused by a yarn version mismatch.

This issue occurred for me because my build server will always install the latest yarn@stable package using corepack prepare yarn@stable --activate

On my local machine I was building and running yarn@3.3.1 which generates a different yarn.lock file when compared to yarn@3.5.0.

As soon as I updated my local yarn version to match my build machine, the lock file regenerated with some changes. Hopefully this helps anyone else coming from the googs!

Problem still exists using yarn 4.x with github action workflow

Hi guys! I am using yarn@3.5.1 and I am still facing the same issue. We use reviewdog to run yarn install which causes the above error. Tried the following things

1. Upgrade yarn to the latest version
2. Delete yarn cache
3. To no avail after the above tries, tried to delete yarn.lock and ran yarn install

Even after the above tries, I still get the same error. Is there any other solution that I can try to fix the error

This might be obvious to others but I recently upgraded Yarn from 4.0.1 to 4.1.0 and hit this issue.

1. I updated my project dependencies (with e.g. npm-check-updates)
2. I run yarn install to install those new deps
3. Yarn tells me a new version is available and I run yarn set version ...
4. I commit and push and receive the error during CI as I am explicitly using yarn install --immutable flag to ensure the builds are repeatable. This was also reproducible locally.

It took me a minute but I thought to run yarn install again and sure enough it modified the checksum entry of each item in the lockfile:

@@ -85,7 +85,7 @@ __metadata:
     magic-string: "npm:0.30.1"
     ora: "npm:5.4.1"
     rxjs: "npm:7.8.1"
-  checksum: f1c3877fe7af6163b8119f15db4d97a0798ae38243e8d955de6da744b54717a21f9f186e197cd4286da3d2c32d605a4ae398ac273402dd62043228a75d836514
+  checksum: 10/f1c3877fe7af6163b8119f15db4d97a0798ae38243e8d955de6da744b54717a21f9f186e197cd4286da3d2c32d605a4ae398ac273402dd62043228a75d836514
   languageName: node
   linkType: hard

So it looks like perhaps 4.1.0 has a new checksum scheme that is not backwards compatible with 4.0.1. That was not obvious in the release notes nor is it immediately apparent you have to run yarn install after yarn set version .

tldr; run yarn install again after upgrading yarn.

Running an install in your repo I see the same changes as the CI, some potential reasons:

• You have a .yarnrc.yml file with packageExtensions higher up the file tree
• You’ve run yarn set version ... in your home directory so it’s using a different version than your CI (check ~/.yarnrc.yml for a yarnPath config)

I ran across the same issue. I resolve dit by deleting my cache and then reinstalling the dependencies.

The yarn.lock file was then modified by the time the reinstall had completed.

I believe this may have been because I checked in the cache folder initially, and then reverted it. Not sure if this then caused a discrepancy between my local environment and the checked-in repo.

Hi! 👋

This issue looks stale, and doesn’t feature the reproducible label - which implies that you didn’t provide a working reproduction using Sherlock. As a result, it’ll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we’re a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it’s a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟