[Bug?]: `yarn workspace version apply` removes deferred versions for other packages

Self-service

• I’d be willing to implement a fix

Describe the bug

I have a workspace that has two packages which do not share a release cycle.

I’m using deferred versioning on the packages with yarn workspace <workspaceName> version <strategy> --deferred, which creates .yarn/versions/<hash>.yml files defining the strategy just for my target workspace, as I would expect.

When I run yarn workspace <workspaceName> version apply, the package.json file for the specified workspace is updated. As expected, the package.json for the other workspaces has not changed. However, the .yarn/versions files have removed the other deferred changes.

To reproduce

I created a minimal repo using yarn berry with a workspace: https://github.com/NikkiDelRosso/yarn-workspace-version-deferred-issue

1. Clone the repo above
2. Run yarn workspace package-b version apply
3. See that the packages/package-b/package.json version number has been bumped
4. See that the packages/package-a/package.json version number has not changed (this is expected)
5. See that the package-a: patch line in in .yarn/versions/27f417a6.yml has been removed
6. Run yarn workspace package-a version apply
7. Receive a message indicating that there is no version bump available for the workspace (even though it should have had been bumped for a patch)

Environment

System:
    OS: macOS 12.5.1
    CPU: (10) arm64 Apple M1 Pro
  Binaries:
    Node: 16.15.1 - /private/var/folders/kc/rkdxxgzx4q1b4cq6mpm343100000gn/T/xfs-80d59fb3/node
    Yarn: 3.2.3 - /private/var/folders/kc/rkdxxgzx4q1b4cq6mpm343100000gn/T/xfs-80d59fb3/yarn
    npm: 8.11.0 - ~/.nvm/versions/node/v16.15.1/bin/npm

[NikkiDelRosso]

Ah, I was digging through the source code to see how this could be fixed and it looks like it’s been addressed by #4336. ~Is there any easy way for me to incorporate this change in my own repo now?~

---

Edit: I built a patched version of the @yarnpkg/plugin-version plugin that cherry picks 5ae7b8a.

I tested this out in my reproduction repository and it seems to work fine.

[yarnbot]

Hi! 👋

This issue looks stale, and doesn’t feature the reproducible label - which implies that you didn’t provide a working reproduction using Sherlock. As a result, it’ll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we’re a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it’s a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟