[Feature] Better UX for yarn set version command

[wdfinch]

• I'd be willing to implement this feature (contributing guide)
• This feature is important to have in this repository; a contrib plugin wouldn't do

Describe the user story
When using yarn set version there are a number of annoying UX issues that make it tedious to change the version in projects. These issues mainly occur when the yarn bin stored in the .yarn/releases folder is not committed to version control which is a common practice (excluding bins). My issues assuming the bin is not committed are:

1. When cloning a new project any yarn command will fail because yarnPath will be set in .yarnrc.yml. Therefore when I try to run yarn set version x on a new project I will get an error saying yarn cannot be found on the yarn path. My workaround is I need to manually remove yarnPath in .yarnrc.yml in order to run set version

2. When running yarn set version after doing the above, my .yarnrc.yml file is completely wiped out and cleaned. I don't understand why changing the yarn version would assume you would want a clean config file.

3. It seems like the version of yarn stored in my /usr/bin/ folder is always 1.x. It would be nice if I could change this to be a version of berry as I have no need for yarn v1 anymore.

Describe the solution you'd like

1. When pulling a fresh project, yarn set version could still work even if a bin is not found in the releases folder and yarnPath is set. Provided the version in /usr/bin/ supports the set version command, it could handle placing the correct version in the releases folder rather than just throwing an error.

2. I don't understand why it would ever be a good idea to wipe the config file if the version is changed. Unless I'm missing something, I think this should be removed.

3. yarn set version could have a -g or global option to update the version in /usr/bin/ . If this is not possible, or there is already a way to do this, it would be great if the docs could tell us how.

Describe the drawbacks of your solution
I don't see any major drawbacks

Describe alternatives you've considered
Right now my workflow when pulling a fresh repo is

1. Remove yarnPath manually
2. Run yarn set version x
3. Pull back my settings that are wiped out from version control and manually change the yarn path again if needed

[arcanis]

These issues mainly occur when the yarn bin stored in the .yarn/releases folder is not committed to version control which is a common practice (excluding bins).

yarn set version is intended for the use case where you check-in the version, so this certainly isn't a common practice (or one we recommend).

When running yarn set version after doing the above, my .yarnrc.yml file is completely wiped out and cleaned. I don't understand why changing the yarn version would assume you would want a clean config file.

That would be a bug, but I strongly doubt it since I use set version a lot.

It seems like the version of yarn stored in my /usr/bin/ folder is always 1.x. It would be nice if I could change this to be a version of berry as I have no need for yarn v1 anymore.

That may be your case, but many people still use Yarn 1, which is why the global binary must remain Yarn 1. We have plans to improve this situation using Corepack (info on this repo with a search).

[wdfinch]

Ok thanks. I will try to create a reproduction of #2.

[merceyz]

When running yarn set version after doing the above, my .yarnrc.yml file is completely wiped out and cleaned. I don't understand why changing the yarn version would assume you would want a clean config file.

That's a bug in v1

[wdfinch]

gotcha. Thanks @merceyz. So assuming I pull a fresh repo with no yarn bin committed and remove the yarnPath so I can run yarn set version, what are my options to not have this happen? At this point, I will be on v1 as this is the version in /usr/bin/. Are there any ways to make the version in /usr/bin/ v2 or higher?