What is the current behavior?
When running yarn install in a package with workspaces, if any of the workspace packages declare a bin in their package.json it's ignored when hoisting dependencies
If the current behavior is a bug, please provide the steps to reproduce.
example repo here: https://github.com/jquense/workspaces-bin-repo
As a little aside if I used a published package name for my test workspaces the local folder would get replaced with the package in the npm registery. Not related to this bug, but maybe a bug anyway.
What is the expected behavior?
That my-test-foo package's bin will be accessible from packages that depend on it.
Please mention your node.js, yarn and operating system version.
node 8.1
yarn 27.5
OSX Sierra
at the behest of @bestander, ping!
@jgoz @arcanis @jquense I think the intended solution to this bug was shipped in 0.28.4. I'm still experiencing the problem on that version though.
If I clone the reproduction @jquense linked to above, then run yarn, then ls -la packages/my-test-bar/node_modules/.bin/ I see eslint is linked, but not bin.js from my-test-foo.
If bin linking was working correctly, I'd expect to see bin.js linked in packages/my-test-bar/node_modules/.bin/ too I think?
@timhaines I don't see it in the release notes and the workspace-fetcher.js file I added isn't in the 0.28.4 tag, so it looks like it wasn't included in that release.
I think last I checked the fix was not in a current release. It's been a bit since a release tho, so hoping we get a new one soon :)
I'm having this same issue with the current release.
@jasonmacdonald As pointed out above, this fix has not been included in a release.
@jgoz yup, just adding my voice to the list of people having issues with this.
@jquense did you ever see this working, I'm having a similar looking issue on switching from npm to yarn recently and I was wondering if this ever got fixed. my understanding is that it would be part of version 1.3.2 of yarn which I am currently running
I'm currently using yarn 1.3.2 as well, and I'm seeing a similar issue as well, potentially the same as @nashspence. When I install packages into a workspace, sometimes they are not being linked into the workspace's node_modules/.bin directory. My workaround currently is to delete all node_modules directories in the project, and reinstall at the root. Then the workspaces get linked properly.
This issue has been fixed since 1.0 (in #3896), so if you still can reproduce it, it probably is a different bug. Since the tests we merged with #3896 are still passing, it would be helpful if you could build a script that we could use to reproduce the problem on our side 馃槂
@arcanis thanks for the response. will do, I'm still looking into what is the cause. will try to work it down to a simplified repro case
so essentially, it seems that my problem is that I have a workspace module that is building scripts that I want to run later in my build. this means, these scripts do not exist at the time when I run the "yarn install" when using "lerna bootstrap --hoist" this seemed to work fine, but yarn workspaces are seemingly not behaving the same in this regard. If, after building the scripts that are declared as bin, I run a "yarn install --force" the bin scripts are then found and linked correctly.
@arcanis Is this the expected behavior with yarn workspaces?
**edit: I have since tried to confirm that "lerna bootstrap --hoist" worked the way that I thought as described above and have been unable to. When I replace yarn workspaces with "lerna bootstrap --hoist" I actually get a similar behavior.
I can confirm the above, except for one thing: lerna bootstrap --hoist is (no longer?) allowed, using the latest yarn (1.19.2) and lerna (3.16.4) versions, so I cannot verify that.
Currently this is what I have to do:
yarn // installs dependencies, including lerna and typescript
yarn compile // alias for `yarn lerna run compile`, compiles ts into js
-> postcompile // alias for `yarn --force`, adds the binary one of my workspaces creates to the root node_modules
It works... but it's not very nice and I've had multiple colleagues ask me "What's up with the force install after compiling?".
so essentially, it seems that my problem is that I have a workspace module that is building scripts that I want to run later in my build. this means, these scripts do not exist at the time when I run the "yarn install" when using "lerna bootstrap --hoist" this seemed to work fine, but yarn workspaces are seemingly not behaving the same in this regard. If, after building the scripts that are declared as bin, I run a "yarn install --force" the bin scripts are then found and linked correctly.
@arcanis Is this the expected behavior with yarn workspaces?
**edit: I have since tried to confirm that "lerna bootstrap --hoist" worked the way that I thought as described above and have been unable to. When I replace yarn workspaces with "lerna bootstrap --hoist" I actually get a similar behavior.
@StephanBijzitter A simpler solution is to have a separate entry point .js file registered as bin that would then require a compiled script. This way yarn will properly link it on the first pass.
Most helpful comment
I can confirm the above, except for one thing:
lerna bootstrap --hoistis (no longer?) allowed, using the latest yarn (1.19.2) and lerna (3.16.4) versions, so I cannot verify that.Currently this is what I have to do:
It works... but it's not very nice and I've had multiple colleagues ask me "What's up with the force install after compiling?".