Package location in .pnp.cgs causes merge conflicts for different platforms

[Poolshark]

Currently, whenever I merge branches in my monorepo, which has been previously updated by my colleague on a Windows machine, the .pnp.cgs causes quite a bunch of merge conflicts since the relative paths to the Yarn cache directory are different

["@aws-crypto/sha256-browser", [\
      ["npm:2.0.0", {\
        "packageLocation": "../../../.yarn/berry/cache/@aws-crypto-sha256-browser-npm-2.0.0-cc43d01c67-9.zip/node_modules/@aws-crypto/sha256-browser/",\
        "packageDependencies": [\
          ["@aws-crypto/sha256-browser", "npm:2.0.0"],\
          ["@aws-crypto/ie11-detection", "npm:2.0.2"],\
          ["@aws-crypto/sha256-js", "npm:2.0.2"],\
          ["@aws-crypto/supports-web-crypto", "npm:2.0.2"],\
          ["@aws-crypto/util", "npm:2.0.2"],\
          ["@aws-sdk/types", "npm:3.193.0"],\
          ["@aws-sdk/util-locate-window", "npm:3.188.0"],\
          ["@aws-sdk/util-utf8-browser", "npm:3.188.0"],\
          ["tslib", "npm:1.14.1"]\
        ],\
        "linkType": "HARD"\
      }]\
    ]],\

Is there a solution to fix this? should we introduce symlinks?

Thanks, any help appreciated!

[arcanis]

You can either make sure the cache is too the same relative location, or disable enableGlobalCache.

[Poolshark]

@arcanis Thanks for the quick response! 🙌

I wasn't aware of the enableGlobalCache option. Somehow it was enabled even though I had set up the project from a fresh Yarn Berry install.

I haven't fully tested this now but when looking through the .pnp.cjs it looks like all folders are now located in the project cache.

Thanks!

[arcanis]

enableGlobalCache is enabled by default on 4.x (currently rc)

[kherock]

@arcanis with enableGlobalCache being enabled by default in v4, it seems like this issue is a missed opportunity to get some of the nice zero-install behavior that project-specific caches checked into git have. We've recently decided to move away from checking caches into git but would like to keep some of the zero-install benefits of having .pnp.cjs checked into source control.

For example, if I'm able to guarantee that my global cache is up-to-date between two branches that I'm working on, I should be able to freely switch between those without regenerating the .pnp.cjs file that is checked into source code. In practice, this lets me go back in time to a commit with an older dependency state without having to run yarn install.

Switching to a project-specific cache with the cache folder gitignored doesn't help, since yarn will prune unused dependencies after installs. I think your suggested answer is that it's possible to fix this by overriding the global folder used with enableGlobalCache enabled, but this isn't very intuitive:

enableGlobalCache: true
globalFolder: ~/.yarn

This works, but it makes managing the offline mirror for multiple projects unwieldy, and it potentially carries other consequences that I'm not aware of.

Would you consider altering the PnP format with some kind of flag to resolve packageLocation paths relative to the global cache folder instead of the project? Or, at the very least, expose a way to disable yarn's cache clean up phase when the global cache is disabled?