Location of global bin doesn't match the doc

[marcandre]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

$ brew install yarn
==> Downloading https://homebrew.bintray.com/bottles/yarn-0.15.1.el_capitan.bott
Already downloaded: /Users/work/Library/Caches/Homebrew/yarn-0.15.1.el_capitan.bottle.tar.gz
==> Pouring yarn-0.15.1.el_capitan.bottle.tar.gz
🍺  /usr/local/Cellar/yarn/0.15.1: 5,239 files, 12.6M
$ yarn global bin
/usr/local/Cellar/node/6.8.1/bin

What is the expected behavior?

Shouldn't yarn global bin output ~/.yarn/bin as per the doc?

Please mention your node.js, yarn and operating system version.

Node v6.8.1
yarn v0.15.1
Os X 10.11.6

[goofansu]

+1

This behaviour is very strange.

[victornoel]

Well, theoretically, yarn global add will create a symlink from the installed package bin to /usr/bin or any other configured bin folder for yarn (which seems to be /usr/local/Cellar/node/6.8.1/bin for homebrew...), so it makes sense.
This is NOT the same thing as ~/.yarn/bin (which is mostly used to store the yarn binary when installed with the shell script)!

Personally, I think that:

• yarn global bin should return ~/.yarn-conf/global/node_modules/.bin which is where globally installed packages are linked for the user.
• yarn global bin should not try to install to /usr/bin or any root-owned directory…

See also #630

[marcandre]

@victornoel I don't have a ~/.yarn-conf/ directory at all, and my ~/.yarn/ directory doesn't have a bin folder in it.

[victornoel]

@marcandre it is normal that the ~/.yarn/ directory doesn't have a bin folder since you installed yarn with homebrew and not by hand using their install script.
And the ~/.yarn-conf/ is only create if you make use of either yarn global or yarn link (and maybe yarn config? not sure), so this is also normal!

Basically your problem is not a problem, it is the expected behaviour of yarn bin (but one can argue that this behaviour is not the best, as I do ^^).

[laduke]

https://yarnpkg.com/en/docs/install for macOS suggests using homebrew,
and suggests Add export PATH="$PATH:$HOME/.yarn/bin"

~/.yarn is empty.
yarn global bin -> /usr/local/Cellar/node/7.0.0/bin is empty except for node.

How would find out where global packages are getting installed?

(it's ~/.yarn-conf/global/node_modules/.bin like mentioned above)

[posva]

The latest version of yarn seems to have ~/.yarn-config/global/node_modules/.bin
So instead of adding export PATH="$HOME/.yarn/bin:$PATH" we have to add

export PATH="$HOME/.yarn-config/global/node_modules/.bin:$PATH"

[markstos]

As of 0.16.1 There's a problem with the design when doing global installs as root. Packages land here /root/.yarn-config/global/node_modules/.bin/ and are symlinked into /usr/local/bin.

However Ubuntu 14.04 and likely other distros set the permissions on /root to disallow group and "other" access into the directory.

So another user will get a "permission denied" error when trying to access the "globally installed" software, even if the user can access /usr/local/bin and if the binary itself is "executable by other".

The design of storing global accessible software software "/root" seems fundamentally broken, since "/root" is often accessible only by root.

I recommend that if the user installing things is root then instead of using /root/.yarn, this root is somewhere globally accessible, like /usr/local/yarn or /opt/yarn.

[indolering]

This is blocking any system-wide usage of JS utilities installed using Yarn.

[mansona]

So from what I can see the folder that yarn installs "global" utilities is ~/.config/yarn/global/node_modules/.bin

I don't know if this right but we've just tested adding that to the path and it seems to work 👍

[sudoforge]

@mansona

So from what I can see the folder that yarn installs "global" utilities is ~/.config/yarn/global/node_modules/.bin

I don't know if this right but we've just tested adding that to the path and it seems to work 👍

That's the "raw location" that symlinks to executables in packages are added to as a result of yarn global add <package>, however yarn global add has an additional step of creating a symbolic link from a "common location" (currently /usr/bin on my system) to the "raw location", presumably for a nicer user experience.

While using a system-wide "common location" might seem like a good idea, I think this is actually anti-pattern from what users expect when running yarn global add -- it was my assumption that "global" was really scoped to my user account, like many other tools that install things in both a project and "user global" scope, like pip, npm, etc...

In my opinion, I think yarn global <subcommand> should really handle managing packages in the user space, in something like $HOME/.yarn/bin, which follows the common pattern from similar tools on *nix systems. This is really a better solution IMO, especially considering that yarn is (generally) installed as a system-wide utility. UserA executing yarn global [add|bin|ls|remove|upgrade] <package> should affect UserB.

Edit:
Actually, in thinking about it, yarn global already deals with packages in the user space, not system. Package symlinks are set up in $HOME/.config/yarn/global/node_modules/.bin as part of the standard installation of packages; so really it is just the default value for yarn global bin that doesn't make any sense. If yarn global handles things in the user space, why is the default bin location (for secondary symlinks) not in the user space?

[Vanuan]

This hit me too. My use case is installing global binaries in Dockerfile (under root) and then running yarn installed binaries under "normal" user. You get permission denied.

[Vanuan]

There are following workarounds:

• add +x permissions to /root which is undesirable
• move yarn config/change all symlinks (not an option)

AFAIK yarn config location is hardcoded to $HOME/.config/yarn so there's not a lot you can do.

[sudoforge]

@Vanuan See #630 (specifically this comment) for a potential workaround.

[markstos]

#3454 only "fixed" this issue for the OS X case, this issue should remain open because the issue was not addressed on other platforms.