yarnpkg
enable fallback to root for scripts/bins
What's the problem this PR addresses?
This PR addresses an issue I noticed while upgrading from yarn v1 to v4: the inability for yarn to fallback to the root workspace for scripts and binaries if not found in the current workspace, while not looking exclusively in either the top level or current workspace.
#6045 ...
How did you fix it?
When we're looking for dependencies/scripts available to the package in getPackageAccessibleBinaries, a new flag tells us whether to limit our search to the current workspace workspace (CW) or, if omitted, expand our search to the root workspace (RW). The edited utility is shared between yarn bin and yarn run and keeps the two consistent.
Flags Added
- For
yarn bin-
-T,--top-level: same behavior as inyarn run -
-C,--current-workspace-only: Limits dep/script search to the CW only
-
- For
yarn run-
-C,--current-workspace-only: As above
-
I edited yarn bin's flags because we get functionality for free from the utils changes, and for consistency with yarn run if the user needs to debug where their running binaries are.
Scripts Behavior Based on the flags, we may check the RW for the script and run the same steps as if a script existed in the CW.
Dependencies Behavior
In getPackageAccessibleBinaries: we start by feeding the RW deps into our set, followed by the CW deps. The "fallback" behavior comes from the insertion order, letting binaries.set(name, ...) prioritize the CW's deps.
New Default Behavior
If RW has jest 29 and CW has jest 28, running jest --version in CW will output 28 and yarn bin jest will output the path to v28.
If flag -T is given, we check the top level only (existing functionality). If -C is specified, no deps outside of CW will be considered. If both are specified, -C takes priority.
...
Checklist
- [x] I have read the Contributing Guide.
- [ ] I have set the packages that need to be released for my changes to be effective.
- [x] I will check that all automated PR checks pass before the PR gets reviewed.
