[Bug?]: The 'workspaces focus ...' command creates an invalid 'install-state.gz' file

[jordanoverbye]

Self-service

• I'd be willing to implement a fix

Describe the bug

The .yarn/install-state.gz file created when running yarn workspaces focus ... is invalid and can cause issues with other commands that depend on the install state (e.g., yarn why, yarn bin).

This issue occurs because the focus command modifies the Yarn project in-memory before calling project.installWithNewReport. Even though project.installWithNewReport is called with persistProject: false, Yarn will always call the persistInstallStateFile method, which will save the modified Yarn project into the install-state.gz file.

This behaviour of Yarn is because of this line in the Project source code https://github.com/yarnpkg/berry/blob/master/packages/yarnpkg-core/sources/Project.ts#L1902. Is this expected behaviour? Or should the install state not get updated if persistProject is disabled?

As a result, any command that depends on data from the install state (e.g., project.storedPackages, project.storedResolutions) can produce incorrect results based on what was previously installed.

To reproduce - Reproduction using yarn why

Reproduction repo: https://github.com/jordanoverbye/yarn-berry-issue-6790-reproduction-1

Reproduction is pretty simple and can be done by creating a basic monorepo with at least two workspaces. In the following example, we have two workspaces, and both workspaces have a single unique external dependency.

simple-monorepo/
├── package-a/
│   └── package.json
│       "dependencies": { "react": "^19.0.0" }
├── package-b/
│   └── package.json
│       "dependencies": { "lodash": "^4.0.0" }

Step 1. Running a yarn why after a regular yarn install works as expected ✅

$ yarn

$ yarn why react
└─ package-a@workspace:package-a
   └─ react@npm:19.1.0 (via npm:^19.0.0)

$ yarn why lodash
└─ package-b@workspace:package-b
   └─ lodash@npm:4.17.21 (via npm:^4.0.0)

Step 2. Running a yarn why after a focused install does not produce accurate results ❌

$ yarn workspaces focus package-a

$ yarn why react
└─ package-a@workspace:package-a
   └─ react@npm:19.1.0 (via npm:^19.0.0)

$ yarn why lodash

# No results returned (Bug)

Step 3. Running a yarn why after a focused install and lockfile update does produce accurate results ✅

$ yarn workspaces focus package-a
$ yarn install --mode update-lockfile

$ yarn why react
└─ package-a@workspace:package-a
   └─ react@npm:19.1.0 (via npm:^19.0.0)

$ yarn why lodash
└─ package-b@workspace:package-b
   └─ lodash@npm:4.17.21 (via npm:^4.0.0)

To reproduce - Reproduction using yarn bin

Reproduction repo: https://github.com/jordanoverbye/yarn-berry-issue-6790-reproduction-2

There's also sometimes issues when using the yarn bin command, and to reproduce the error we can use the same simple monorepo structure as before, just with different dependencies that contain a bin path.

Note: This appears to only be an issue for dependencies that are specified in multiple workspaces, and resolve to the same location.

simple-monorepo/
├── package-a/
│   └── package.json
│       "dependencies": { "jest": "^29.0.0" }
├── package-b/
│   └── package.json
│       "dependencies": { "jest": "^29.0.0" }

Step 1. Getting the bin for jest works as expected after a regular install ✅

$ yarn
$ cd package-b
$ yarn bin jest
# simple-monorepo/node_modules/jest/bin/jest.js

Step 2. Getting the bin for jest works as expected after a lockfile update ✅

$ yarn install --mode update-lockfile
$ yarn bin jest
# /simple-monorepo/node_modules/jest/bin/jest.js

Step 3. Getting the bin for jest works as expected after a focused install ✅

$ yarn workspaces focus package-b
$ yarn bin jest
# /simple-monorepo/node_modules/jest/bin/jest.js

Step 4. Getting the bin fails after a lockfile update, but only if it happens after a focused install ❌

$ yarn install --mode update-lockfile
$ yarn bin jest
# Usage Error: Couldn't find a binary named "jest" for package "package-b@workspace:package-b"

Step 5. Run the previous steps in the package-a directory and you'll see that everything works as expected 🤔

Step 6. If you change the ranges of Jest so they do not match, everything works as expected for package-a and package-b 🤔

Environment

System:
    OS: macOS 15.4.1
    CPU: (12) arm64 Apple M3 Pro
  Binaries:
    Node: 22.11.0 - /private/var/folders/57/kvlkrpjd70bfdqk50m4z8n9w0000gn/T/xfs-d619771b/node
    Yarn: 4.9.1 - /private/var/folders/57/kvlkrpjd70bfdqk50m4z8n9w0000gn/T/xfs-d619771b/yarn
    npm: 10.9.0 - ~/.nvm/versions/node/v22.11.0/bin/npm

Additional context

I am willing to contribute a fix.