What determines the resolution hash value? Seeing differences on CI vs locally for local package

[E-PressSend]

Discussed in #2605

^{Originally posted by ercgrat March 16, 2021}
Created a package within a package to create a custom eslint plugin. Added it like so: yarn add --dev ./eslint. The resulting yarn.lock entry contains a checksum. When yarn is run on CI and on GitHub actions, there is no checksum and the hash value in resolution is also different. What's accounting for this and can I control it? I realize creating a true repo and publishing this eslint package would be a workaround, but seems silly for a one-liner.

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

These are the only two resources I have found that seem relevant:
yarnpkg/yarn#1916
https://stackoverflow.com/questions/49501749/is-it-possible-to-ignore-the-dependency-hash-validation-of-just-one-module-or-r

[RDIL]

Can you provide a reproduction?

[BlueSialia]

I'm experiencing a similar issue. yarn install generates a lockfile which then I push and when my CI system runs yarn install --immutable it fails with The lockfile would have been modified by this install, which is explicitly forbidden because some hash changes:

➤ YN0000: ┌ Post-resolution validation
➤ YN0000: │ @@ -34838,23 +34838,21 @@
➤ YN0000: │  "typescript@patch:typescript@~4.7.4#~builtin<compat/typescript>":
➤ YN0000: │    version: 4.7.4
➤ YN0028: │ -  resolution: "typescript@patch:typescript@npm%3A4.7.4#~builtin<compat/typescript>::version=4.7.4&hash=a1c5e5"
➤ YN0028: │ +  resolution: "typescript@patch:typescript@npm%3A4.7.4#~builtin<compat/typescript>::version=4.7.4&hash=7ad353"
➤ YN0000: │    bin:
➤ YN0000: │      tsc: bin/tsc
➤ YN0000: │      tsserver: bin/tsserver
➤ YN0028: │ -  checksum: 9096d8f6c16cb80ef3bf96fcbbd055bf1c4a43bd14f3b7be45a9fbe7ada46ec977f604d5feed3263b4f2aa7d4c7477ce5f9cd87de0d6feedec69a983f3a4f93e
➤ YN0000: │    languageName: node
➤ YN0000: │    linkType: hard
➤ YN0000: │  
➤ YN0028: │ The lockfile would have been modified by this install, which is explicitly forbidden.
➤ YN0000: └ Completed

Why are those hashes and checksums different just by running yarn install on a different machine? What is used to calculate those hashes?

[kauffmanes]

Came to ask this question too. I recently upgraded from yarn 1 to 3 and I'm running into this. I'm using yarn workspaces but not the PnP yet.

➤ YN0000: │  "typescript@patch:[email protected]#~builtin<compat/typescript>":
➤ YN0000: │    version: 4.7.3
➤ YN0028: │ -  resolution: "typescript@patch:typescript@npm%3A4.7.3#~builtin<compat/typescript>::version=4.7.3&hash=a1c5e5"
➤ YN0028: │ +  resolution: "typescript@patch:typescript@npm%3A4.7.3#~builtin<compat/typescript>::version=4.7.3&hash=701156"
➤ YN0000: │    bin:
➤ YN0000: │      tsc: bin/tsc
➤ YN0000: │      tsserver: bin/tsserver
➤ YN0028: │ -  checksum: 137d18a77f52254a284960b16ab53d0619f57b69b5d585804b8413f798a1175ce3e774fb95e6a101868577aafe357d8fcfc9171f0dc9fc0c210e9ae59d107cc0
➤ YN0000: │    languageName: node
➤ YN0000: │    linkType: hard

Things I've tried:

• Downgrading to TS 4.7.3 (still failed)
• Downgrading yarn back to 1 (build worked)
• Adding yarn range to engine in package.json (failed)
• removing node_modules/yarn.lock and reinstalling (failed)
• Running yarn with immutable locally (no yarn lock change)
• Tried different ranges (4.7.4 with ^, ~, and without - all failed)
• yarn cache clean --all
• yarn dedupe

I'm at a loss! Anyone figure this out yet? I can remove the immutable flag and the build works but I'd like to get it back in there.

[merceyz]

It seems like your CI is using a different version of Yarn than what you're using locally, are you running yarn set version ... on your CI?

[kauffmanes]

@merceyz my local is 3.2.3 (yarn -v) In my Dockerfile, I'm doing this:

RUN yarn set version berry
RUN yarn install --immutable

Looks like berry is 3.2.3. Should that be 'stable' instead? Or just set the specific version?

• Trying it with RUN yarn set version 3.2.3, TBD...

[merceyz]

RUN yarn set version berry

That will resolve to the latest version which at the time of writing is v3.2.4.

Should that be 'stable' instead?

stable and berry is the same version in this case.

Or just set the specific version?

Ideally you would copy the CLI into the container but specifying the same version would also work.

[kauffmanes]

Setting the version explicitly fixed my issue, so thank you!

As for copying the CLI, right now I'm doing this:

ADD package.json yarn.lock .yarnrc.yml ./
ADD .yarn ./.yarn

What would I need to copy the CLI?

[merceyz]

That should do it, I do something similar in my Dockerfile's combined with the following .dockerignore

.yarn/*
!.yarn/cache
!.yarn/releases
!.yarn/plugins
!.yarn/patches
.pnp.*

[yarnbot]

Hi! 👋

It seems like this issue as been marked as probably resolved, or missing important information blocking its progression. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it.

[mikz]

I have the same problem, but with 3.3.1 on local macOS and on Netlify.

@RDIL @merceyz Looks like it was caused by .DS_Store files that are in .gitignore (well, globally defined in ~/.gitconfig).

Reproduction is quite easy. Have a local package, open it in Finder, do some clicking like open folders in tree view and run yarn rebuild package-name. And it will regenerate the hash.

[jonathanj]

Patches (created with yarn patch) also seem to trigger this issue quite reliably, adding a new patch will almost always cause yarn to fail with "YN0028: The lockfile would have been modified by this install" citing the patch in the output.

In my case the whole .yarn folder is in the repository and the versions of Yarn are the same.

[kgutwin]

One workaround I found for this issue was to use yarn link --relative ../path/to/other-package after yarn add ../path/to/other-package. This adds a "portal" in package.json that looks like this:

{
  "resolutions": {
    "other-package": "portal:../path/to/other-package"
  }
}

With this, yarn stops checking the checksum when you do a yarn install --immutable.