[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

[lolmaus]

• [ ] I'd be willing to implement a fix

Describe the bug

When I run yarn install and then git status I can see that there are no changes since the last commit, i. e. yarn.lock does not get modified by running yarn install.

Yet, when I push the commit to CI that has this GitHub Actions step:

      - name: Install dependencies
        run: yarn install

...it fails with:

2021-05-28T13:48:22.9912155Z ➤ YN0028: The lockfile would have been created by this install, which is explicitly forbidden.
2021-05-28T13:48:22.9913523Z ➤ YN0000: Failed with errors in 0s 12ms
2021-05-28T13:48:22.9918681Z ##[error]Process completed with exit code 1.

It's weird that the error message is saying "created". I was not able to google up any mentions of this specific error message. All mentions of YN0028 say "modified", not "created".

I believe this is a bug since doing yarn install locally does not modify yarn.lock, which exists and is checked into the repo.

To Reproduce

I do not have a minimal reproduction, but here's a failing CI job: https://github.com/kaliber5/ember-bdd/actions/runs/885833497

It references a commit of a public open source project on GitHub.

I was able to work around the prpblem by setting the YARN_ENABLE_IMMUTABLE_INSTALLS env var to false. But it does not explain why Yarn is not able to use the lockfile.

Environment if relevant (please complete the following information):

• OS: Ubuntu 20.04
• Node version: 14
• Yarn version: 3.0.0-rc.2

Additional context

The project is a Yarn Workspaces monorepo.

[merceyz]

which exists and is checked into the repo.

Looking at the repo you linked to you haven't commited the lockfile, you're actually ignoring it https://github.com/kaliber5/ember-bdd/blob/63c5ffbda1d4884c432056d3f4f8c2ad1ee18e91/.gitignore#L16

[lolmaus]

which exists and is checked into the repo.

Looking at the repo you linked to you haven't commited the lockfile, you're actually ignoring it https://github.com/kaliber5/ember-bdd/blob/63c5ffbda1d4884c432056d3f4f8c2ad1ee18e91/.gitignore#L16

Argh, dunno where that came from. Some faulty boilerplate, probably. Thanks for pointing that out.

Unfortunately, this didn't help me: after un-ignoring the lockfile, checking it into the repo and removing YARN_ENABLE_IMMUTABLE_INSTALLS=true, I now receive the more common error:

YN0028: │ The lockfile would have been modified by this install, which is explicitly forbidden.

Here's the GitHub action failing: https://github.com/kaliber5/ember-bdd/runs/2704378275?check_suite_focus=true

Running yarn install locally, followed by git status, reveals no changes made to the lockfile.

So the bug still stands, I believe.

[merceyz]

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)

[lolmaus]

You have a .yarnrc.yml file with packageExtensions higher up the file tree

I do have a .yarnrc higher up, in the home folder, but it's a v1, no .yml extension, and it does not cotnain a packageExtensions directive.

---

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)

Nope, I did not ever run yarn set version outside of this project folder.

---

Running an install in your repo I see the same changes as the CI

I have cloned the repo to a new folder and ran yarn. The lockfile did get modified, I have committed it, and the CI now passes.

But in the original project folder, git status reported no changes and no untracked files. The only difference must have been in the node_modules/ folder and the .yarn folder which Yarn itself added to .gitignore (with exceptons).

Doesn't that indcate some kind of bug? Non-determinstic behavior?

[lolmaus]

PS @merceyz Thank you for pointing me to the direction of resolving my CI issue. 🙏

[ylemkimon]

The diff at https://github.com/kaliber5/ember-bdd/commit/4d75a555198b3cc3f047275821addf81bc473ce3#diff-51e4f558fae534656963876761c95b83b6ef5da5103c4adef6768219ed76c2deL19350 shows a workspace named test-app got removed.

[lolmaus]

The diff at kaliber5/ember-bdd@4d75a55#diff-51e4f558fae534656963876761c95b83b6ef5da5103c4adef6768219ed76c2deL19350 shows a workspace named test-app got removed.

@ylemkimon Thank you for noticing and pointing it out.

But why was it removed? The actual files of the workplaces are intact at apps/test-app/, and the workspaces definition at the root package.json did not change:

  "workspaces": {
    "packages": [
      "apps/*",
      "addons/*"
    ]
  },

[yarnbot]

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! 🌟

[lolmaus]

Okay, my problem was that the workspace was accidentally committed into the repo as a git submodule, so no workspace files existed on the remote. That workspace existed only in my local repo.

Since the workspace contained a package.json, it resulted in a lockfile discrepancy.

[andrico1234]

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.

[mfb-davidmay]

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!

[punndcoder28]

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

[cmoulliard]

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

[nonoesp]

A clean clone and yarn fixed this CI issue for me — the cacheKey in yarn.lock got updated to match the one in the CI.

YN0028: The lockfile would have been modified by this install, which is explicitly forbidden.

[zaventh]

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.

[badvision]

If you are not using the same exact version of node in your dev machine as you are in CI/CD, expect problems related to this regarding hashes being different. I just ran into this problem with typescript support module being different going from node 20.9.0 to 20.16.0. This makes consistent builds absolutely impossible across even minor versions of node.