Do you want to request a _feature_ or report a _bug_?
Bug
What is the current behavior?
bin field in its package.json.yarnls -al node_modules/.bin/What is the expected behavior?
At least that is what npm does and we started depending on it.
Please mention your node.js, yarn and operating system version.
Yarn: 0.16.1
Node: v6.7.0
OS: macOS Sierra
e.g. @jokeyrhyme/node-init: just something I put together to keep certain conventions consistent across all my Node.js projects
yarn global add @jokeyrhyme/node-init
node-init --version
# => zsh: command not found: node-init
npm install --global @jokeyrhyme/node-init
node-init --version
# => 1.6.0
Would love to see this fixed. npm scripts referencing local binaries must inconveniently use the full paths. Thanks!
Whenever I run yarn add I need to follow this up afterwards with npm install cross-env mocha.
Back to npm we go.
+1
Looks like this was fixed in #3310 (same as https://github.com/yarnpkg/yarn/issues/2758#issuecomment-325733171)
This should be able to be closed 馃憤
It's not working for me for locally installed packages on version 1.13.0
my bad see comment below
Neither is it working with global packages.
@bestander any thoughts on this?
Actually, switching to npm, I realized the package was had errors in the binary names. Npm fails with an ENOENT error at install which is ok. Yarn succeeds without any warning.
I think Yarn should at least issue a warning or maybe just fail to remain in sync with Npm behavior. An explicit error would be good to. Maybe something like: Executable 'xxx' with path 'bin/xxx' does not exist in the package.
And I agree with @lukebatchelor it should be closed as it's resolved (it will make it clear to everyone it's closed and they should triple check the packages).
Thanks, @sandorfr
Most helpful comment
Would love to see this fixed. npm scripts referencing local binaries must inconveniently use the full paths. Thanks!