[Feature] yarn global

[a-gerescher]

• I'd be willing to implement this feature
• This feature can already be implemented through a plugin

Describe the user story

After the upgrade my global packages are not installable/removable/updateable any more.
Please bear with me, if i don't fully understand all concepts included. But i tried to google/search all issues/read the documentation and nowhere is a sentence about global binaries/packages.

Describe the solution you'd like

As an angular developer i am only able to update my build environment if '''yarn global''' is included.

Describe the drawbacks of your solution

As i said i am unsure if i fully understand all concepts and if '''yarn global''' has been left out intentionally.

Describe alternatives you've considered

After the upgrade my global packages are not installable/removable/updateable any more.

[arcanis]

The yarn global workflow is replaced by yarn dlx for one-shot scripts. If you need to regularly call the commands, add them to your regular dependencies and use yarn <binary name>.

[smarts]

1. @arcanis I'm not sure that fully answers the question… if it does, I'm not sure I understand what command I'd use to remove or update global packages that are already installed prior to upgrading yarn.
2. I want to temper the following statement by saying I think that overall yarn is great.
   That said… yuck. I know that the argument for forcing users to type 5 extra characters is probably something like "that's not difficult", but let's face it: we're lazy 🤷‍♂️
   IMHO, completely removing a core feature that probably a very high percentage of users rely on is a surefire way to get people to avoid upgrading or to move away from the toolchain completely (i.e., back to npm)

I don't know if this is set in stone yet, but I hope the team will reconsider. This is also a call to action for users: Upvote this if you feel the same way I do.

[arcanis]

I'm not sure I understand what command I'd use to remove or update global packages that are already installed prior to upgrading yarn

For that you need to remove the folders manually. I don't recall where they are exactly depending on the system but they should be near your home folder.

removing a core feature that probably a very high percentage of users rely on is a surefire way to get people to avoid upgrading or to move away from the toolchain

You're right... Kinda. The thing is, adding commands just for the sake of "why not? We might lose users otherwise" just doesn't really make the cut for me. Such things have a cost not only in number of keystrokes, but also maintainance time. Working on Yarn is already fairly intense, I'm not sure it's necessarily a bad thing for the future of a community open source project to put maybe less weight into "growth hacking", and instead focus on making working on the project a joy rather than a burden.

That being said, I'm fairly sure it would take me less than two hours to build a prototype yarn global plugin by copy-pasting the code of dlx with a few changes. So maybe someone with two extra hours I don't have will take ownership and build it, and maintain it! Not everything has to belong to the core, and not everything has to be maintained by the same set of people. It's certainly a shift in how the project works, but with some understanding I think we can get past that together 😊

And for all those that don't agree with my philosophy, fear not! Just imagine the 2.x doesn't exist and it'll be the exact same thing. Use the 1.x trunk, it'll always be exactly as good as it is now 😉

[smarts]

Thanks @arcanis! That's a [mostly] fair response 🙂
I would like to clarify that, IMHO, it's not quite

adding commands just for the sake of "why not? we might lose users otherwise"

although I concede that if you were to look at 2.x as a brand new tool rather than an upgrade of an existing tool, then it would make perfect sense. I look at it as an upgrade, hence my divergent stance.

All that aside, is it possible to get specific instructions on cleaning up global packages added to the migration guide? (IIRC I think I saw such a thing)

Thanks again for all the hard work!

[joerideg]

ok so I understand that one-off scripts are quite doable with the speed yarn has and its cache. However does this not impact a lot cli tools out there that expect to be installed in some global folder? Not all tools are necessarily bound to projects with a package.json. For example I use 'live-server' all the time just to start up some random folder. Now it takes 3 seconds extra to start up with yarn dlx live-server . Seems like a waste.

[larixer]

@joerideg I'm not sure what your point is, given that @arcanis has already stated:

That being said, I'm fairly sure it would take me less than two hours to build a prototype yarn global plugin by copy-pasting the code of dlx with a few changes. So maybe someone with two extra hours I don't have will take ownership and build it, and maintain it! Not everything has to belong to the core, and not everything has to be maintained by the same set of people.

So anyone can step in and build this feature and maintain it. For the set of people that currently work on v2 this feature is not a top priority at the moment.

[joerideg]

I ment to point out that, unless I am missing something, yarn dlx does not seem to be a complete replacement for globally installed packages and this change might have unintended impact on already existing packages and tools (such as @angular/cli). Considering globally installed packages were actually a core feature of yarn 1 (and, correct me if I'm wrong, all other common package managers), and @arcanis pointed out it would be quite easy to implement, I would suggest the core team does pick it up (at some point) or showcase in documentation how they envision using yarn dlx to replace typical usages of yarn global.
Just like the OP I ended up here trying to find a way of installing the few global tools I use, as documentation of this intended replacement does not seem available yet.

[jakst]

[...] or showcase in documentation how they envision using yarn dlx to replace typical usages of yarn global.

I agree strongly here. Being used to running yarn global [...] in v1, I feel confused in v2.

Reducing the API surface and maintenance burden in v2 is probably necessary fo the longevity of the project, but it really does make the migration hard and confusing. A document detailing the thoughts behind the removal of the command and how new commands can replace old workflows would help a lot. Maybe even leaving the command yarn global in there, but instead printing a message that the command has been removed in v2 and print a link to the text with the reasoning behind it.

[arcanis]

Yep, that's very reasonable. I'll add a few missing "bridges" in the next release 👍

[a-gerescher]

Thank you very much. I just want to add that in some cases you don't have a package.json when you wanted to run yarn dlx, and sometimes you need additional packages / eg. eslint @typescript-eslint/eslint-plugin to run your command. Would be nice if you cover these cases as well.

[fabis94]

There are many cases of CLI tools that you'd want available system-wide, it's very strange that this very commonly used and necessary feature has been just dropped without any replacement

[arcanis]

There are many cases of CLI tools that you'd want available system-wide

I haven't said there isn't.

We simply don't see Yarn as a system package manager. It can be used to power a system package manager, but we don't really want to deal with the wiring needed to make that work, especially considering that we don't really use it ourselves (and I think that for something to be worthy of being in our repository, maintainers have to dogfood it).