yarn <executable> with workspaces doesn't work anymore

[thallada]

What is the current behavior?

I recently upgraded to yarn 1.15.2 from 1.13.0 and now running executables inside <current_workspace>/node_modules/.bin/ no longer works. It looks like it is always looking for executables in the root workspace.

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

In a repo with yarn workspaces, cd into one of the workspaces and try to run a command that only exists in that workspace's ./node_modules/.bin.

> yarn react-native
yarn run v1.15.2
error Command "react-native" not found.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

> ls ./node_modules/.bin/react-native
./node_modules/.bin/react-native

What is the expected behavior?

That it runs the executable in the current folder's ./node_modules/.bin.

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

yarn: v1.15.2
node: v8.14.0
os: macOS Mojave 10.14

[scastiel]

Hi! _./node_modules/.bin/react-native_ should be a symlink, and sometimes I have this error because the symlink points to a non-existent file. What does ls ./node_modules/.bin/react-native give?

[thallada]

> ls -l ./node_modules/.bin/react-native
lrwxr-xr-x  1 thallada  staff  47 Mar 18 11:06 ./node_modules/.bin/react-native@ -> ../react-native/local-cli/wrong-react-native.js

Not sure what's with the wrong-react-native bit, but that file does exist. This happens for other binaries in the folder too:

> ls -l ./node_modules/.bin/metro
lrwxr-xr-x  1 thallada  staff  19 Mar 18 11:06 ./node_modules/.bin/metro@ -> ../metro/src/cli.js

> yarn metro
yarn run v1.15.2
error Command "metro" not found.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

> ./node_modules/.bin/metro
Commands:
  build <entry>  Generates a JavaScript bundle containing the specified
                 entrypoint and its descendants
  serve          Starts a Metro server on the given port, building bundles on
                 the fly

Options:
  --help     Show help                                                 [boolean]
  --version  Show version number                                       [boolean]

Not enough non-option arguments: got 0, need at least 1

[rally25rs]

I was unable to reproduce on 1.15.2:

~/Projects/yarn-test2 🐒   yarn --version
1.15.2

~/Projects/yarn-test2 🐒   cat package.json
{
  "name": "yarn-test2",
  "private": true,
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
  },
  "workspaces": [
    "packages/*"
  ]
}

~/Projects/yarn-test2 🐒   cat packages/pkg1/package.json
{
  "name": "pkg1",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "jest": "^24.5.0"
  }
}

~/Projects/yarn-test2 🐒   yarn install
yarn install v1.15.2
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning "workspace-aggregator-11c7d15f-bc58-478a-a93d-74189a581632 > pkg1 > jest > jest-cli > @jest/core > [email protected]" has unmet peer dependency "jest-resolve@^24.1.0".
warning "workspace-aggregator-11c7d15f-bc58-478a-a93d-74189a581632 > pkg1 > jest > jest-cli > jest-config > [email protected]" has unmet peer dependency "jest-haste-map@^24.0.0".
[4/4] 🔨  Building fresh packages...

success Saved lockfile.
✨  Done in 2.56s.

~/Projects/yarn-test2 🐒   ll packages/pkg1/node_modules/.bin
total 8
drwxr-xr-x  3 jvalore  891112136   102B Mar 18 11:10 .
drwxr-xr-x  3 jvalore  891112136   102B Mar 18 11:10 ..
lrwxr-xr-x  1 jvalore  891112136    41B Mar 18 11:10 jest -> ../../../../node_modules/jest/bin/jest.js

~/Projects/yarn-test2 🐒   cd packages/pkg1/

~/Projects/yarn-test2/packages/pkg1 🐒   yarn jest
yarn run v1.15.2
$ /Users/jvalore/Projects/yarn-test2/node_modules/.bin/jest
 PASS  ./some.test.js
  pkga
    ✓ has tests (5ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        1.24s
Ran all test suites.
✨  Done in 2.06s.

Could you maybe make a small repro example? Maybe it's only an issue with certain packages?

[thallada]

I made a minimal repro example here: https://github.com/thallada/yarn-executable-bug

I think this is due to using nohoist on the package I am trying to execute. It's really common to nohoist react-native because the scripts and bundler don't respect workspaces.

This definitely used to work in yarn as late as v1.14.0. On v1.15.0 or later I get the "command not found" error.

[robations]

I have this problem with a monorepo using lerna, yarn workspaces, and typescript.

From the root of the project:

$ yarn tsc --version
yarn run v1.15.2
$ /path/to/root/node_modules/.bin/tsc --version
Version 2.9.2

$ cd packages/subproject

$ ls -l node_modules/.bin/tsc 
lrwxr-xr-x  1 robations  staff  43 26 Mar 16:34 node_modules/.bin/tsc -> ../../../../node_modules/typescript/bin/tsc

$ yarn tsc --version
yarn run v1.15.2
$ /path/to/root/node_modules/.bin/tsc --version
Version 2.9.2       # <--- expected Version 3.3.333̇

so looks like the symlink in the subproject is wrong in this case. (I deleted all node_modules/ directories and reinstalled everything before re-testing this.)

[robbymarston]

This is occurring for me as well and doesn't appear to be isolated to workspaces. This closed issue is still reproducible on my machine.

With this configuration:

package.json

...
"scripts": {
  "test": "jest"
}
...

Running yarn test throws the following error:

yarn run v1.15.2
$ jest 
/bin/sh: 1: jest: not found

However, running yarn jest functions correctly. Downgrading to Yarn v1.14.0 seems to resolve the issue as well.

[rally25rs]

Sorry for the long delay on getting back to this issue...
It looks like I inadvertently broke it in #6850 😞

I changed from a config.cwd to config.lockfileFolder as the base path when looking for bins while trying to fix handling of the --modules-folder parameter.

I'll work up a PR to resolve this as soon as I can...

[simonbuchan]

I think I have the same issue as @robations, roughly:

packages/a -> [email protected]
packages/b -> [email protected]

causes node_modules/.bin/webpack to point to 3.x.x, seemingly as it was the alphabetically last package with a webpack bin :/

The above fix should fix it, but perhaps just not hoisting bin stubs would be more correct?

Edit: nope, the trigger isn't quite that simple...

[danrr]

Hi @rally25rs, mind if I ask if there are any updates on the fix for this? I've run into this when using nohoist, and tried out your fix locally. It worked a treat. I'm happy to help move it along if there's anything I can do. Thanks!

[Amy-Lynn]

Is there any update on this? It's a pretty significant issue.