Better handling of nested executable script

[jourdain]

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

feature/bug

What is the current behavior?

Let's pretend your project "A" has a dependency on "B" and "B" has a dependency on "Webpack", "ESlint" and more CLI...

Those CLI will be stored inside {A}/node_modules/B/node_modules/.bin/* which will prevent any CLI from working within project "A".

It will be nice to have B CLI's available in A, like npm 3+ do.

I see several options:

1. Gather any nested CLI to the root ./node_modules/.bin
2. Gather only global package to the root
3. Add metadata inside package.json for project like B that act as meta-packages.

If the current behavior is a bug, please provide the steps to reproduce.

$ mkdir tmp
$ cd tmp/
$ yarn init
$ yarn add kw-web-suite
$ ls node_modules/.bin/
  fix-kw-web-suite
$ ls node_modules/kw-web-suite/node_modules/.bin/
  commitizen  eslint  git-cz  semantic-release  shjs  webpack  webpack-dev-server

What is the expected behavior?

I would expect to see node_modules/kw-web-suite/node_modules/.bin/ inside node_modules/.bin/

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

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.11.6
BuildVersion:   15G1004
$ node --version
v6.3.1
$ yarn --version
0.15.1

[DanielZlotin]

I would like to add that for me, using 0.15.1 on node 6.7.0, OSX El capitan:
when installing regular open source projects from npmjs, yarn installs node_modules/.bin.
The issue occurs only when installing from private repositories, then yarn doesn't event create the .bin folder at all, although the rest of node_modules looks fine.

[DanielZlotin]

In the mean time I'm using this gist to just mimic what npm usually does with all executables under node_modules (symlinks them into node_modules/.bin): https://gist.github.com/DanielZlotin/4199f3dd85d1b952117ea260a99fdb72

[jourdain]

nice! Thanks for sharing

[DanielZlotin]

OK so further testing reveals the problem to be completely different: this has nothing to do with private repositories and can be reproduced using npmjs.
This only happens to inner dependencies.

For example: if you have in your dependencies eslint, the resulting node_modules/.bin is:

eslint -> ../eslint/bin/eslint.js

But, if you remove everything from dependencies and put, say, standard, using yarn, you get only this single file under node_modules/.bin:

standard -> ../standard/bin/cmd.js

notice no eslint executable is present, even though standard brings eslint transitively.

To compare, here is the resulting install of a single dependency standard using npm 3:

drwxr-xr-x   12  361602828   408B Oct 18 20:19 .
drwxr-xr-x  146  361602828   4.8K Oct 18 20:19 ..
lrwxr-xr-x    1  361602828    18B Oct 18 20:19 acorn -> ../acorn/bin/acorn
lrwxr-xr-x    1  361602828    23B Oct 18 20:19 eslint -> ../eslint/bin/eslint.js
lrwxr-xr-x    1  361602828    25B Oct 18 20:19 esparse -> ../esprima/bin/esparse.js
lrwxr-xr-x    1  361602828    28B Oct 18 20:19 esvalidate -> ../esprima/bin/esvalidate.js
lrwxr-xr-x    1  361602828    25B Oct 18 20:19 js-yaml -> ../js-yaml/bin/js-yaml.js
lrwxr-xr-x    1  361602828    20B Oct 18 20:19 mkdirp -> ../mkdirp/bin/cmd.js
lrwxr-xr-x    1  361602828    16B Oct 18 20:19 rimraf -> ../rimraf/bin.js
lrwxr-xr-x    1  361602828    19B Oct 18 20:19 shjs -> ../shelljs/bin/shjs
lrwxr-xr-x    1  361602828    22B Oct 18 20:19 standard -> ../standard/bin/cmd.js
lrwxr-xr-x    1  361602828    29B Oct 18 20:19 strip-json-comments -> ../strip-json-comments/cli.js

As you can see, every transitive dependency which has an executable defined under package.json bin is getting linked in the top-most node_modules/.bin folder.

[DanielZlotin]

Something to do with this commit maybe? 986938e?diff=unified#diff-163b16ac3f2b452cccb80bff414a566cL167

[jkimbo]

@DanielZlotin you were right about that commit! I've created a PR that should fix this issue: #1210

[DanielZlotin]

Just wanted to share this https://github.com/wix/yarn-bin-fix. This is a temporary fix to our migration pains.