enable fallback to root for scripts/bins #6047
Draft
+84
−48
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 betweenyarn bin
andyarn run
and keeps the two consistent.Flags Added
yarn bin
-T,--top-level
: same behavior as inyarn run
-C,--current-workspace-only
: Limits dep/script search to the CW onlyyarn run
-C,--current-workspace-only
: As aboveI edited
yarn bin
's flags because we get functionality for free from the utils changes, and for consistency withyarn 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, lettingbinaries.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 andyarn 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