[Bug?]: Running 'yarn set version' in home directory overrides per-repo Yarn versions
Self-service
- [X] I'd be willing to implement a fix
Describe the bug
"I tried running Yarn v2 CLI on a Yarn v1 project and can't figure out how to get it to run in classic mode. Even with yarn set version classic it keeps trying to upgrade my repo." (complaint tweet)
"You have a .yarnrc.yml in your home directory that contains a yarnPath pointing to ~/.yarn/releases/xxx.js" (Correct solution from @arcanis)
"For that to happen, you probably accidentally ran yarn set version inside your home directory rather than an individual project. Perhaps something we should hard block 🤔" (Additional info from @arcanis)
To reproduce
Sorry, I don't see how to reproduce this with Sherlock. In general I think the steps are something like:
- Run
yarn set version latestin~ -
cdinto some path like~/repos/my-repothat uses Yarn v1 -
yarn
Environment
Note that this is just from one repo. I got 'dlx is not found' on my Yarn v1 repos. And whoops, it's Yarn v3, not v2 as in the reports.
System:
OS: Linux 5.10 Ubuntu 20.04.3 LTS (Focal Fossa)
CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
Binaries:
Node: 16.14.0 - /tmp/xfs-cbcaba7c/node
Yarn: 3.1.0-rc.7.git.20210926.hash-f0d86bd4 - /tmp/xfs-cbcaba7c/yarn
Additional context
I think this is different from #4362, but I'm not very familiar. Sorry if it isn't! 🙂
I am coming here because I am confused with this behavior. yarnPath is set in yaml, but when running yarn install in a different enviornment, it does nothing. Trying to set the version again causes this to error saying that release is not in the releases folder. So, I am not sure what the correct pipeline for CI/CD should be. Docs don't seem to provide any clarity on the matter of version management and locking. Are we supposed to commit .yarn directory to version control?
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! 🌟
@arcanis could you please grant the upholded label? I would like to send a PR to fix this, as long as it'd be accepted. 🙂
Sure! I think just blocking yarn set version in the home directory would be reasonable (and perhaps add a --skip-home-check in case someone really needs it?)
@merceyz you indicated in https://github.com/yarnpkg/berry/pull/4664#pullrequestreview-1050115833 that just blocking yarn set version in the home directory isn't enough, and that we should tackle the root issue. What do you see as the root issue here? That home directory yarn config files are overriding project configs?
Can we put the version in .yarnrc similar to other rc files? Eg .nvmrc version is within, so when I nvm install and nvm use, this file ver is prioritized.
Any chance you can speed up that review, @JoshuaKGoldberg ? While tackling the main issue is great, we need a temp workaround better than just uninstalling yarn3 and reinstalling old yarn for each project :) This also leaves room for error.
As an update, I feel like this is only happening in powershell (or any Windows shell)? When I drop to bash, it seems working. Windows only bug?
Any chance you can speed up that review, @JoshuaKGoldberg?
It's not under my control 😄. I'm an external contributor, waiting on more info from the maintenance team to help me address a set of PR comments I don't fully understand.
Windows only bug?
No, this happened for me on my macOS Monterey terminal.
For clarity: I just repro'd this in a bash profile on an alt laptop, too.
I ran into the same issue with even the latest version (3.6.0), any updates on this? I'm using macOS Ventura
Quite annoying problem. Any process on it?