[Bug] .bin resolving order is wrong when using yarn workspace

[sglim]

Expected

In yarn workspace, yarn run command use package dependent binary instead of root one.

Actual

yarn run uses root binary when there are different binary versions

How to reproduce?

See https://github.com/sglim/yarn-workspace-bin-bug

[rally25rs]

I believe this is as-designed. I ordered the .bin resolution specifically in that order a few years ago #4543 (comment) because if you are running a command for a specific package, it should use that package's explicit dependency before falling back to the workspace root.

When you run yarn commands from within a workspace package, yarn considers you to be operating on that package. In your example, cd packages/workspace-1 ; yarn add leftpad would add leftpad as a dependency to workspace-1 's package.json only, not to workspace-2 or to the workspace root.

Likewise, running yarn run from within the packages/workspace-1 directory considers you to be operating on workspace-1 and will use it's .bin folder first.

[devurandom]

I appear to be running the same problem. In a project with two workspaces that use different versions of Cypress, 11.2.0 and 13.4.0, yarn workspaces run cypress version executes the root module's node_modules/.bin/cypress (which happens to be 11.2.0) instead of a workspace-dependent version, even though myworkspace/node_modules/.bin/cypress exists and points to myworkspace/node_modules/cypress/bin/cypress in both cases.

[benzittlau]

@rally25rs It appears you might have misread the report. The OP was saying that the expected behaviour is that yarn run would utilize the package's explicit dependency before falling back to the root (as you state the behaviour should be), but what they were actually observing is that it was utilizing the root version of the package instead.

I am observing this same behaviour with yarn 1.22.22 and attempting to utilize a different eslint version via yarn run within the package.

Here's a repo with reproduction steps:
https://github.com/benzittlau/yarn-workspace-package-version-bug

[rally25rs]

ohhh I see! Sorry @benzittlau , my comment was partially correct in that yarn will run the correct script and also sets the PATH correctly sometimes. It looks like there is a case where it does not. I appreciate the sample project. That helps a lot.

OK so after some testing:

---

1. yarn sets the PATH correctly to have the workspace package's .bin first, before the root .bin.

Can see this by adding a script to package.json in a sub package:

"scripts": {
  "path": "echo $PATH"

then run

yarn workspace workspace-a run path

outputs (replaced ':' with newline to make its readable)

/var/folders/2k/gl0z9w3s0wv01mnwn5mv59zm0000gn/T/yarn--1720231136138-0.14349062450304784
/Users/jeff/Projects/yarn-workspace-package-version-bug/src/apps/workspace-a/node_modules/.bin
/Users/jeff/.config/yarn/link/node_modules/.bin
/Users/jeff/Projects/yarn-workspace-package-version-bug/node_modules/.bin
/Users/jeff/.yarn/bin
/Users/jeff/.config/yarn/global/node_modules/.bin
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin

which would handle any other child processes that get executed, since it would resolve src/apps/workspace-a/node_modules/.bin before node_modules/.bin

---

2. if a script is defined in package.json then the correct bin is executed.

for example if you edit both workspace-a/package.json and workspace-b/package.json and add the script

"scripts": {
  "lint": "eslint --version"

then execute them, they now work as expected:

$ yarn workspace workspace-a run lint

v8.57.0

$ yarn workspace workspace-b run lint

v7.32.0

---

3. what does not seem to work is simply running abin that is installed by a transitive dep, that isn't a package.json script.

$ yarn workspace workspace-a run eslint --version

v7.32.0

$ yarn workspace workspace-b run eslint --version

v7.32.0

This appears to be related to this getBinEntries method: https://github.com/yarnpkg/yarn/blob/master/src/cli/commands/run.js#L28

I think the problem is that the return value is a Map<string, string> that maps script names to paths.
It checks the workspace first and adds

eslint = yarn-workspace-package-version-bug/src/apps/workspace-a/node_modules/.bin/eslint

then runs through the workspace root next, and ends up replacing the workspace-specific eslint with

eslint = yarn-workspace-package-version-bug/node_modules/.bin/eslint

It seems like the order would need to either be reversed, or check first to see if a script is already in the map, and don't replace it if it is.

---

Reopening this issue, however please note that the timeline for fixing things in yarn classic/v1 that aren't critical (yarn no longer works at all) or a security vuln, aren't added that often, so not sure if/when this would get fixed. Upgrading to yarn modern is always a solid suggestion (we are up to v4 now, so bug fixing v1 hasn't been a priority for ~3 years).

In the meantime, you can also work around this by adding the command as a script in package.json as shown in 2) above.

[benzittlau]

@rally25rs Awesome, thanks so much for digging into that. We played around with it a bit further here and similarly discovered that the $PATH appeared to have the correct sequencing, but beyond that we were running into the limits of our knowledge to investigate further. Knowing about the workaround via a package.json script helps a lot.