[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).

[Prefinem]

I would like to also point out, yarn global has been a life saver for me when installing a git repo globally.

Running yarn dlx http://github.com/Prefinem/some-node-program every time will essentially make me move away from yarn (not that one person should matter for the change).

I could use npm for global packages and yarn for everything else, but that seems fragmented and wrong. Yarn used to be an npm replacement, but not matching features or actively removing matched features seems like a move backwards.

[Tiedye]

I understand why the global install was removed, however I don't understand why yarn2 depends on yarn1 to work. What is wrong with installing yarn2 globally as you would every other package manager I can think of and use it only for dependency management within projects?

[sfcgeorge]

• I agree with @Tiedye that it's super confusing (even as an existing Yarn 1 user) that the instructions for fresh installing Yarn 2 involve installing Yarn 1 by first following some other instructions. Imagine how confusing that must be for new users.
• The name berry makes things even more confusing. The install instructions say you have to run yarn set version berry for some reason. What is berry? How am I supposed to know that berry means 2? Does the berry command actually install Yarn 2 or do I then have to do yarn install, and which version is actually doing the installing at that point?
• Can Yarn 2 just be installed with a system package manager like apt-get or brew? I guess not if you need yarn to run the berry command.
• It's fine if tha maintainers don't want/use global in Yarn, but what do the maintainers use to install global CLI tools? Yarn 1? That seems backwards. Npm? Extract a zip into a folder? The docs just say global is gone but don't provide any advice on what to use instead.
• I have the same confusion over messaging as @Prefinem, I thought Yarn was meant to fully replace NPM, is that no longer the goal? Is Yarn 2 designed to be used in tandem with NPM, or with something else?

[arcanis]

So... This thread is about yarn global. Opinions regarding the project name, or installation method, or whether you will migrate from 1 to 2, or ..., are largely off topic. I appreciate that many of you took the time to express opinions in a constructive way (I didn't hide your comments because you clearly put work to formulate them and I want to recognize this), but this topic is about the global subcommand.

If you have specific ideas to improve the migration path (which is something I wholeheartly agree with), please open dedicated issues - or, even better, contribute a PR or two! Ask everyone who contributed so far, I think they'll tell you how reactive we are on PRs.

I'll now close this since I don't plan to have any news about this in the immediate future. If you want yarn global so bad, implement it as a plugin, solve the footholes, and prove us that the value outweighs the cost by carrying it for a while. Until then, this isn't something I'm interested to maintain, so you won't find it here.