[Bug?]: .pnp.cjs needs different packageLocation values on different machines

[MCFX2]

Self-service

• I'd be willing to implement a fix

Describe the bug

Our project uses Yarn with zero installs. Everything more or less works. However, the .pnp.cjs file is different on my machine compared to another, which means one of us will always have to run yarn/yarn install to get the project to actually run (and that of course generates a change which Git would like to check in).

Here's an example of a package we use (Vite) that's different:

Machine A:

["vite", [\
      ["npm:5.0.11", {\
        "packageLocation": "../../../.yarn/berry/cache/vite-npm-5.0.11-d5457a8b86-10c0.zip/node_modules/vite/",\
    ....

Machine B:

  ["vite", [\
      ["npm:5.0.11", {\
        "packageLocation": "../../.yarn/berry/cache/vite-npm-5.0.11-d5457a8b86-10c0.zip/node_modules/vite/",\
    ....

As you can see, there's an extra ...

The other type of change involves the location of virtual packages:
A:

["virtual:1342a1fa4d6cf1d17d01bcd8d630514f1dfb981d201f3a317381d8434f28051d9e5fb5c92940a744d14b778264b7600297107a687a82dfffea2ad599210abf09#npm:5.0.11", {\
        "packageLocation": "./.yarn/__virtual__/vite-virtual-9e412c4134/4/.yarn/berry/cache/vite-npm-5.0.11-d5457a8b86-10c0.zip/node_modules/vite/",\

B:

["virtual:1342a1fa4d6cf1d17d01bcd8d630514f1dfb981d201f3a317381d8434f28051d9e5fb5c92940a744d14b778264b7600297107a687a82dfffea2ad599210abf09#npm:5.0.11", {\
        "packageLocation": "./.yarn/__virtual__/vite-virtual-9e412c4134/3/.yarn/berry/cache/vite-npm-5.0.11-d5457a8b86-10c0.zip/node_modules/vite/",\

In this case they're identical except one is in /3/ and the other is in /4/.

This isn't a huge deal, we can just add .pnp.cjs to the gitignore and get used to running yarn install more often. But the docs say we should be checking this file in so I'd rather not do that.

To reproduce

This is difficult to provide a repro for, since I assume it's coming from something in one of our environments. It affects every single package we have installed.

Environment

Machine A:
  System:
    OS: Linux 6.8 Arch Linux
    CPU: (16) x64 AMD Ryzen 7 2700X Eight-Core Processor
  Binaries:
    Node: 20.12.0 - /tmp/xfs-69f9c613/node
    Yarn: 4.1.0 - /tmp/xfs-69f9c613/yarn
    npm: 10.5.0 - ~/.nvm/versions/node/v20.12.0/bin/npm

Machine B:
  System:
    OS: Linux 5.15 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
    CPU: (4) x64 Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz
  Binaries:
    Node: 20.12.0 - /tmp/xfs-bcfeca0d/node
    Yarn: 4.1.0 - /tmp/xfs-bcfeca0d/yarn
    npm: 10.5.0 - ~/.nvm/versions/node/v20.12.0/bin/npm

Additional context

No response

[MCFX2]

After some investigation, it seems like the issue is related to where machine A and B have cloned the repo to. Machine A's enlistment is located at ~/A/B, and machine B is at ~/A/B/C, and for some reason .pnp.cjs is using a relative path to find the home directory, which (predictably) breaks across environments. Maybe related to #4030 .

[arcanis]

A current limitation is that the relative path between the project and the global cache must be the same between machines when using enableGlobalCache: true (which is the default).

We use relative paths for better portability since absolute paths would likely be always broken, and the .pnp.cjs has no knowledge of Yarn's internal algorithms (like the one which locates the Yarn cache on disk, which may be different depending on the .yarnrc.yml content).

[MCFX2]

Yeah, I see that now. I agree then that this isn't a bug and the behavior makes sense. I think the documentation should be more clear that zero installs require the global cache to be disabled, the only mention of it I can find is on this page, which requires reading a lot of context (skipping directly to the "Zero Installs" section means you miss essential information). It's not mentioned in more visible places(1) people are likely to find(2), with that second page being what people see when they click on the "zero installs" reference on the FAQ page.

[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.

[andrewzey]

Thanks to all who helped resolved this.

The bug would be that the tooling for doing an ugprade from Yarn 3 to Yarn 4 (yarn set version berry) automatically added enabledGlobalCache: true to our .yarnrc.yml even though we had zero install setup.

Ideally the automatic upgrade would detect zero install and add this to the .yarnrc.yml: enableGlobalCache: false # because yarn zero install requires it