Do you want to request a feature or report a bug?
bug
What is the current behavior?
Running yarn link in a local project with a bin-script specified in package.json doesn't put a symlink to the script in the global bin directory (yarn global bin).
If the current behavior is a bug, please provide the steps to reproduce.
In a project folder with the following files:
package.json
{
"name": "foo",
"version": "1.0.0",
"bin": {
"foo": "index.js"
},
"license": "MIT"
}
index.js
#! /usr/bin/env node
console.log('bar baz');
run yarn link.
What is the expected behavior?
The foo command should be available in the PATH,
foo
#=> bar baz
and a foo symlink should be present in the yarn global bin directory
ls $(yarn global bin) | grep foo
#=> foo
Please mention your node.js, yarn and operating system version.
MacOS Sierra, Version 10.12
Node v5.4.0
Yarn 0.16.1
the same problem (Yarn 0.17.9, Windows 7, Node 6.8.1, Gulp 3.9.1)
In my case:
$(yarn global bin) is /usr/local/bin.I tried yarn global add webpack.
It did install it to ~/.config/yarn/global/node_modules/webpack/, and did add a symlink from ~/.config/yarn/global/node_modules/.bin/webpack to ~/.config/yarn/global/node_modules/webpack/bin/webpack.js.
But it seems to have failed to add a symlink to /usr/local/bin/webpack. Perhaps it's a permissions issue (because /usr/local/bin isn't writable by my user)? Though I tried both with and without sudo, and neither worked.
This does not work on Windows where .cmd files are created in the bin directory for all the binaries - it is not enough to just symlink.
How is this a bug? Surely a local yarn install shouldn't put _anything_ in a global area.
This caught me out too. To clarify, this is the behaviour of npm:
[npm link will] link any bins in the package to {prefix}/bin/{name}
@MikeTaylor Perhaps you're misunderstanding what the point of yarn link is. yarn/npm link isn't for manipulating the project's local workspace, it's for making the project globally available to other projects, via a symlink.
Could be. We abandoned yarn link entirely in our project: it just doesn't work.
(Not just in this respect, I mean. All sorts of pervasive problems.)
Do you use a different mechanism for working on command line tools? yarn link isn't working for me either, but I can't figure out what a good alternative to it is (short of just moving back to npm).
We've found workspaces get us closer to where we want to be. Beyond that we're also using a tool of our own that builds and runs the specific large system we're working on. It's a real shame that Yarn, which we all thought was going to fix everything we hated about NPM, ended up introducing other stuff that also doesn't work, but in different ways.
Still, I do recommend workspaces.
Is there a way to get this working with yarn create? I'm trying to test it with a package I'm developing locally after linking it globally, and it seems to forcibly add/install the package from the registry ignoring my locally linked version, which I can run by using the command directly without yarn create. It works if I try the same with npm init or npm create.
I have a fix: https://github.com/yarnpkg/yarn/pull/7543
In my case:
* Node 6.9.2, Yarn 0.17.10, OS X. * `$(yarn global bin)` is `/usr/local/bin`.I tried
yarn global add webpack.It _did_ install it to
~/.config/yarn/global/node_modules/webpack/, and _did_ add a symlink from~/.config/yarn/global/node_modules/.bin/webpackto~/.config/yarn/global/node_modules/webpack/bin/webpack.js.But it seems to have failed to add a symlink to
/usr/local/bin/webpack. Perhaps it's a permissions issue (because/usr/local/binisn't writable by my user)? Though I tried both with and withoutsudo, and neither worked.
@jetpack I have the exact same issue with yarn 1.21.1. Is there a bug report for this issue somewhere here?
@jetpack nevermind. I found the explanation in the last paragraph under Path Setup.
To have access to Yarn鈥檚 executables globally, you will need to set up the PATH environment variable in your terminal. To do this, add export PATH="$PATH:
yarn global bin" to your profile
Most helpful comment
How is this a bug? Surely a local yarn install shouldn't put _anything_ in a global area.