berry: [Bug?]: checksum is different from windows and unix for local packages

Self-service

  • I’d be willing to implement a fix

Describe the bug

Yarn computes a different checksum for local packages (ie. packages installed via a relative path) on windows vs linux, causing yarn install to fail in CI.

To reproduce

  • Run yarn add ../relativePath followed by yarn install on windows.
  • Commit changes and attempt to run yarn install in CI on linux.

Run yarn install
➤ YN0000: · Yarn 4.0.2
➤ YN0000: ┌ Resolution step
Resolution step
➤ YN0000: └ Completed in 0s 566ms
➤ YN0000: ┌ Post-resolution validation
Post-resolution validation
➤ YN0028: -  resolution: "platformed-browser-api@file:../browser-api#../browser-api::hash=516e63&locator=platformed-frontend%40workspace%3A."
➤ YN0028: -  checksum: f4cc44353a17885d87d70800a9a43b4d88bc68aa81c1ae9177775ef4fe5f47ecc2a469e21f3615d3bd08f7b83c3e9e7b7980ecdcc8e76ff069f1c5bf7487deab
➤ YN0028: +  resolution: "platformed-browser-api@file:../browser-api#../browser-api::hash=cab6bb&locator=platformed-frontend%40workspace%3A."
➤ YN0028: The lockfile would have been modified by this install, which is explicitly forbidden.
➤ YN0000: └ Completed
➤ YN0000: · Failed with errors in 0s 695ms
Error: Process completed with exit code 1.

Environment

System:
    OS: Windows 10 10.0.19045
    CPU: (20) x64 12th Gen Intel(R) Core(TM) i9-12900H
  Binaries:
    Node: 18.12.1 - ~\AppData\Local\Temp\xfs-2d93d2cb\node.CMD
    Yarn: 4.0.2 - ~\AppData\Local\Temp\xfs-2d93d2cb\yarn.CMD
    npm: 9.2.0 - C:\Program Files\nodejs\npm.CMD

Additional context

Related issues: https://github.com/yarnpkg/berry/issues/5136 https://github.com/yarnpkg/berry/issues/2774

About this issue

  • Original URL
  • State: open
  • Created 5 months ago
  • Reactions: 2
  • Comments: 17 (3 by maintainers)

Most upvoted comments

Folks, isn’t it about checksums of packages being calculated on the compressed versions of packages vs the “raw” packages from npm? See my issue from some time ago where I learned about this: #5957

Try setting compression level to 0 in the project – maybe the differences are due to how the compression algorithm works on various OS?

Thanks for the suggestion, I hadn’t seen that bug. But 1) I’m not using a package from npm - it’s a simple file: entry consisting of a webpack bundle + package.json, 2) my issue didn’t occur after upgrading from yarn 3 to 4, we’ve been on v4 all along, 3) our compressionLevel was already set to 0 everywhere

And P.S. I agree this is highly annoying, seems to be pretty widespread, and so I’m baffled as to why the maintainers are ignoring it.

How do we get a “maintainer to explicitly vouch for it”? Do we have to wave arms in the comments until it draws attention? 😂

Folks, isn’t it about checksums of packages being calculated on the compressed versions of packages vs the “raw” packages from npm? See my issue from some time ago where I learned about this: https://github.com/yarnpkg/berry/issues/5957

Try setting compression level to 0 in the project – maybe the differences are due to how the compression algorithm works on various OS?