Yarn: Scoped binary deps are not added to node_modules/.bin

Created on 26 Oct 2016  路  9Comments  路  Source: yarnpkg/yarn

Do you want to request a _feature_ or report a _bug_?

Bug

What is the current behavior?

  • Add a dependency to a scoped package that has a bin field in its package.json.
  • Run yarn
  • ls -al node_modules/.bin/
  • This does not include symlinks to the binaries defined by the scoped package or its dependencies.

What is the expected behavior?

  • There should be symlinks to the binaries defined by the scoped package.
  • There should be symlinks to the binaries defined by the dependencies of the scoped package.

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

Most helpful comment

Would love to see this fixed. npm scripts referencing local binaries must inconveniently use the full paths. Thanks!

All 9 comments

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

Was this page helpful?
0 / 5 - 0 ratings