Repository navigation
Installation instructions cause yarn 3 to be installed globally #5410
Description
Activity
Those are the docs of Yarn 3 though, so I'll move this issue to the right repo
Reacted by Nick MullerThis doesn't make sense to me, why should you have yarn 1 installed globally when it's total legacy at this point? Like how would you be able to use
yarn dlxglobally when you still have version 1 in the path? (unless you happen to be in a Yarn Berry project)Reacted by Dan Rose and Brennan Kinney@simonhaenisch I think I explained it confusingly. I meant that if you want to use Yarn 1, it is recommended to install it globally.
The reason I have installed it globally, is because I have multiple projects that still use it. Those broke when installing yarn 3 via the official instructions.
This doesn't make sense to me, why should you have yarn 1 installed globally when it's total legacy at this point? Like how would you be able to use yarn dlx globally when you still have version 1 in the path? (unless you happen to be in a Yarn Berry project)
This is how I found this issue. I'm literally wondering how
dlxis supposed to work ifyarn@1is what we all have installed globally.Reacted by Simon HänischBest solution forward for me: start using Corepack (
corepack enable), thencorepack prepare yarn@stable --activateto make Yarn Berry available globally.Then just set
"packageManager": "yarn@1.22.19"in old projects andyarn@3.6.0for new ones (or start using4.0.0-rc.45already). Mostly saves you from needing to commit.yarnas well (unless you need some plugins of which most are now shipped automatically with Yarn 4 anyway).Just saw that Corepack is the recommended way of installing Yarn now anyway.
Reacted by Brennan Kinney and Harper AndrewsReacted by gabrieluc-sapThen just set
"packageManager": "yarn@1.22.19"in old projects andyarn@3.6.0for new ones (or start using4.0.0-rc.45already)This workflow doesn't work when I have to interact with legacy projects that use Yarn 1.x and I can't touch
package.json. Right now I need to contribute to an open-source project, but I don't want to updatepackage.jsonas part of my pull request.Reacted by Brennan Kinney and Harper AndrewsIndeed that seems to be a problem in the doc. You can do it, but our general recommendation is to keep Yarn@1 as global binary (that's why we don't push modern releases to the
yarnnpm package anymore).I'll fix that later today, sorry for the confusion.
Reacted by Nick MullerThis seems like a weird decision... how can it be recommended to keep Yarn 1 as a global binary when it's development has been frozen for years meaning it won't even receive security patches? And again the question, how would I use
yarn dlxglobally outside a Yarn Berry workspace?Regarding the comment about working with legacy projects: I've not found it hard to skip/revert the
packageManagerfield when committing 🤷🏻♂️ But I also don't see how it would be problematic for Yarn 1 projects to accept the field in a PR. It's not like they need to worry about updating it 😅meaning it won't even receive security patches?
We still commit to release critical security fixes if they arise.
I've not found it hard to skip/revert the packageManager field when committing 🤷🏻♂️ But I also don't see how it would be problematic for Yarn 1 projects to accept the field in a PR. It's not like they need to worry about updating it 😅
It's not hard, but it's still something they need to do. People don't like unforeseen friction on projects that already work for them. Our policy has been "new releases of Yarn are much better by every metrics, but if your current project works fine then don't feel obligated to migrate".
Of note, back when we released Yarn 2.0 we were a little too hasty, and it caused a significant backlash. I think most of the problems from the 2.0 have disappeared since then, but I'm very cautious and prefer to take things as slow as needed to be fully safe. The first step will probably to switch the
yarn initfrom the 1.x Yarn to set thepackageManagerfield to 4.0, so new projects created forward get migrated over, but even that won't be done right at release.Using a global binary for Yarn was a really bad idea in retrospect, but we have to live with it ... 😅
Reacted by Nick Muller, Brennan Kinney and Yehyoung KangReacted by Simon HänischThe
packageManagerfield makes things even more confusing. If it says"packageManager": "yarn@3.0.0", it looks like that means "the yarn package at version 3.0.0" but in fact, it means an entirely different package. IMO, putting this under theyarnpackage is the right thing to do, even if thelatesttag points at 1 for historical reasons.Reacted by Simon Hänisch
Unless I'm mistaken it's recommended to install yarn 1 globally and enable yarn 3 per project.
Following the installation instructions however causes yarn 3 to be installed globally, breaking yarn 1 projects:
https://yarnpkg.com/getting-started/install#updating-the-global-yarn-version
Wouldn't it be better to install yarn 1 globally through
corepack prepare yarn@classic --activate?