Yarn: Workspaces: linking node_modules/.bin to wrong directory

Created on 15 May 2018  路  6Comments  路  Source: yarnpkg/yarn

Yarn 1.6.0, node 8.9.4 on OS X High Sierra

I suspect this is a bug in workspaces but I could be incorrect about that.

I discovered that node_modules/.bin/mocha is linked to the first package in my workspace to use mocha.

However, Yarn also decided to install mocha in node_modules, resulting in this curious little bit of behavior:

$ node_modules/.bin/mocha --version
5.1.1
$ node_modules/mocha/bin/mocha --version
3.5.3

Expected behavior:
The contents of node_modules/.bin should always point to ../../node_modules/*/bin (custom bin: properties notwithstanding).

It makes me wonder if the bin folder is being evaluated in the wrong order, causing it to make decisions on incomplete or simply different information.

Edit: nohoist has no effect on the behavior

triaged

All 6 comments

I am still seeing this problem with 1.12

bug is still existing, plz halp

I think I checked again in 1.15 and still saw the same issue. This blocks us from using yarn, and npm keeps finding new ways to make the wrong design choices (latest one is 'lock file' not behaving as a lock file).

@jdmarshall for now I fixed it by removing broken node_modules/ and symlinking root. Ofc in postinstall callback in package json

This is still an issue with 1.21.

I'm seeing new behavior with 1.21.1 and I'm wondering if https://github.com/yarnpkg/yarn/pull/7755 is involved.

Mocha and a few other things are behaving, but I'm not out of the woods yet. One, node-gyp is bailing out on hashring and/or node-syslog so the install never finishes. npm runs just fine.

For the subset of things that did install, the remaining bin links into my workspace directory:

  • 2 modules tooling modules I have checked out in the workspace (expected behavior)
  • nyc (despite node_modules/nyc existing)
  • pm2 (despite node_modules/pm2 existing)
Was this page helpful?
0 / 5 - 0 ratings