getting YN0028 The lockfile would have been modified by this install, which is explicitly forbidden. using yarn berry and heroku

Viewed 8451

I'm using yarn berry and heroku and consistently getting the error:

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

Which suggests that my lockfile does not contain all my listed dependencies. In the yarn docs it says this is easily solved by running yarn install and pushing new lockfile to git. However I've tried this, tried with fresh node_modules, etc with no luck.

Has anyone else experienced this issue using yarn berry + heroku?

My repo is a monorepo using workspaces.

3 Answers

I was able to workaround by setting the env-var YARN_ENABLE_IMMUTABLE_INSTALLS to false, as suggested here.

This is likely a bug in Yarn Berry. I've reported it here: https://github.com/yarnpkg/berry/issues/2948


UPD: I have created a fresh local clone of the repo from GitHub, ran yarn install in it, and it did produce changes in yarn.lock. Committing those changes resolved the CI issue, so disabling YARN_ENABLE_IMMUTABLE_INSTALLS is no longer necessary for me.

The original local repo showed a clean git status, so I still believe it is a bug.

UPD 2: My problem was that one of the Yarn worspaces was checked into git as a git submodule (I have probably created it with a nested .git/ folder and then deleted it). As a result, the workspace content, including a child package.json was not committed into the repo, it only existed in my local repo and not on the remote and CI.

After removing the git submodule and checking the workspace into the repo properly, the YN0028 error stopped happening.

If your ENV doesn't contain any CI variables:

Then it could be your yarn config:

Run yarn config get enableImmutableInstalls and see if it's enabled. (you can also check why it is enabled by running yarn config --why and looking for enableImmutableInstalls).

If it is true, then run yarn config set -H enableImmutableInstalls false to set the setting's value globally (or without the -H argument to set it only in your current project)

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.

Related