yarn <executable> with workspaces doesn't work anymore #7126

thallada · 2019-03-18T14:47:16Z

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

The text was updated successfully, but these errors were encountered:

scastiel · 2019-03-18T14:58:54Z

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 · 2019-03-18T15:12:39Z

> 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 · 2019-03-18T15:13:30Z

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 > jest-resolve-dependencies@24.5.0" has unmet peer dependency "jest-resolve@^24.1.0".
warning "workspace-aggregator-11c7d15f-bc58-478a-a93d-74189a581632 > pkg1 > jest > jest-cli > jest-config > jest-resolve@24.5.0" 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 · 2019-03-18T15:57:08Z

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 · 2019-03-26T16:53:04Z

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 · 2019-03-27T03:19:14Z

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 · 2019-03-27T12:41:38Z

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...

…nds. Fixes run in workspaces. This fixes a bug that was introduced in yarnpkg#6850 where the bin path was being built only from `config.lockfileFolder`. However in workspaces, bins may not be hoisted to the workspace root, causing bins to not be found. This change adds `config.cwd` to the bin search path, so the `yarn run` command will look in a workspace package's node_modules, as well as the workspace root. fixes yarnpkg#7126

simonbuchan · 2019-04-10T02:45:00Z

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

packages/a -> webpack@4.x.x
packages/b -> webpack@3.x.x

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 · 2019-07-23T23:16:45Z

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 · 2019-09-09T18:04:24Z

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

* fix(run): change run command to check cwd/node_modules/.bin for commands. Fixes run in workspaces. This fixes a bug that was introduced in #6850 where the bin path was being built only from `config.lockfileFolder`. However in workspaces, bins may not be hoisted to the workspace root, causing bins to not be found. This change adds `config.cwd` to the bin search path, so the `yarn run` command will look in a workspace package's node_modules, as well as the workspace root. fixes #7126 * modify chagelog

…kg#7151) * fix(run): change run command to check cwd/node_modules/.bin for commands. Fixes run in workspaces. This fixes a bug that was introduced in yarnpkg#6850 where the bin path was being built only from `config.lockfileFolder`. However in workspaces, bins may not be hoisted to the workspace root, causing bins to not be found. This change adds `config.cwd` to the bin search path, so the `yarn run` command will look in a workspace package's node_modules, as well as the workspace root. fixes yarnpkg#7126 * modify chagelog

rally25rs mentioned this issue Mar 27, 2019

fix(run): add cwd/node_modules/.bin to run command search path #7151

Merged

arcanis closed this as completed in #7151 Oct 30, 2019

GulajavaMinistudio mentioned this issue Oct 30, 2019

Fix switch statement exhaustiveness checking GulajavaMinistudio/yarn#304

Merged

priceld mentioned this issue Dec 9, 2019

yarn bin <executable> returns the wrong path when executable is hoisted and installed in workspace #7748

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

yarn <executable> with workspaces doesn't work anymore #7126

yarn <executable> with workspaces doesn't work anymore #7126

thallada commented Mar 18, 2019 •

edited

scastiel commented Mar 18, 2019

thallada commented Mar 18, 2019

rally25rs commented Mar 18, 2019

thallada commented Mar 18, 2019

robations commented Mar 26, 2019

robbymarston commented Mar 27, 2019

rally25rs commented Mar 27, 2019

simonbuchan commented Apr 10, 2019 •

edited

danrr commented Jul 23, 2019

Amy-Lynn commented Sep 9, 2019

yarn <executable> with workspaces doesn't work anymore #7126

yarn <executable> with workspaces doesn't work anymore #7126

Comments

thallada commented Mar 18, 2019 • edited

scastiel commented Mar 18, 2019

thallada commented Mar 18, 2019

rally25rs commented Mar 18, 2019

thallada commented Mar 18, 2019

robations commented Mar 26, 2019

robbymarston commented Mar 27, 2019

rally25rs commented Mar 27, 2019

simonbuchan commented Apr 10, 2019 • edited

danrr commented Jul 23, 2019

Amy-Lynn commented Sep 9, 2019

thallada commented Mar 18, 2019 •

edited

simonbuchan commented Apr 10, 2019 •

edited