[Bug?]: `yarn set version` sets `yarnPath` in `.yarnrc.yml` when using corepack to manage versions

[qcn]

Self-service

• I'd be willing to implement a fix

Describe the bug

Corepack is now the recommended way to install/manage Yarn versions and according to the docs it

lets you use different package manager versions across multiple projects without having to check-in the Yarn binary anymore

However, running yarn set version to update Yarn sets yarnPath in the .yarnrc.yml file, so if I check in the other changes made by set version without checking in the binary, trying to run Yarn errors if the binary isn't there (eg. on a fresh checkout).

Given that the documentation says I don't need to check in the Yarn binary, I expect that using the CLI to lock my package manager version in the documented way will not make any changes that would require the binary to be in that location.

To reproduce

1. Run corepack enable
2. Create a new directory with a package.json file containing only:

{ "packageManager": "yarn@3.1.0" }

3. Run yarn -v and observe that it succeeds - corepack is handling it.
4. Run ls -a and observe that the package.json file is the only file in this directory.
5. Run yarn set version 3.1.1.
6. Run rm .yarn/releases/yarn-3.1.1.cjs
7. Run yarn -v and observe the error:
   Internal Error: The "yarn-path" option has been set, but the specified location doesn't exist.
8. Run yarn config unset yarnPath
9. Run yarn -v and observe that it succeeds - corepack is handling it again now that the change yarn set version made to yarn config has been reverted.

Environment

System:
    OS: macOS 11.6.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 14.19.0 - /private/var/folders/n7/8y3h45rn5jq9lrd744w_m7xh0000gn/T/xfs-8cbd9b83/node
    Yarn: 3.1.1 - /private/var/folders/n7/8y3h45rn5jq9lrd744w_m7xh0000gn/T/xfs-8cbd9b83/yarn
    npm: 6.14.16 - ~/.nvm/versions/node/v14.19.0/bin/npm

Additional context

No response

[merceyz]

This is on purpose, the fact that the system running the command has Corepack enabled doesn't mean another system does. To make sure systems without Corepack use the correct version it sets both.

[qcn]

This is on purpose, the fact that the system running the command has Corepack enabled doesn't mean another system does. To make sure systems without Corepack use the correct version it sets both.

My understanding is that with this configuration Corepack won't be used, as it will prefer the yarn path. So in that case, isn't it misleading to suggest that Corepack provides the benefit of not having to check in the binary, given that the same page also directs you to run yarn set version "any time you want to update" and commit the results?

[arcanis]

Yes and no. Updating the binary in the repo, is temporary, until Corepack gets available in all LTS releases. I think for Yarn 4 we'll consider only updating the package.json.

[qcn]

Yes and no. Updating the binary in the repo, is temporary, until Corepack gets available in all LTS releases. I think for Yarn 4 we'll consider only updating the package.json.

That makes sense, thank you for considering that! (I got very excited when I updated Node and saw Corepack in the release notes, so I jumped straight to trying it on our project.) I'll continue to use our current setup until Yarn 4 in that case.

[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! 🌟

[alper98]

This is still the case for me. Following the migration guide and running yarn set version berry still adds the yarnPath in my .yarnrc.yml file while also downloading the cjs

[vishnup-ditto]

This is still the case for me. Following the migration guide and running yarn set version berry still adds the yarnPath in my .yarnrc.yml file while also downloading the cjs

Similar update as this. The weirder part of me is it doesn't create a yarnPath for me in my linux machine, but it does for my colleague on a Windows machine. We both have corepack enabled. I think this is worth checking into again.