fix: workspace incorrectly resolves node_modules path during script execution on windows (fixes #4564) #9078
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.
Background Summary
The issue arises from the way Yarn handles symlink paths for executable files in node_modules.
When executables like rimraf.cmd are run from symlinked directories (like those under /node_modules/@pkg/a/node_modules/.bin), the paths resolve incorrectly relative to the repository root.
This problem is caused because Yarn adds the symlink path instead of the real, resolved path to the PATH environment variable. As a result, relative paths calculated in scripts point incorrectly, leading to failure in locating the correct files (e.g., prisma\build\index.js).
More Detail: #4564 (comment)
Severity & Notes
This issue has been a pervasive one, having been first reported over 7 years ago. I've run into it multiple times and the severity is such that it entirely cripples complex projects.
It appears to also be present in Yarn 3.
I have a fix submitted, but I'm also submitting multiple solution proposals. I'm happy to discuss these with the team and do whatever is most suitable.
I noticed that some patches are still being accepted for Yarn 1, which are not strictly security related, so I'm hopeful we can get this through as well.
With that said, I am also willing to address it in Yarn 3+ if need-be to get this merged, however, I'd love to get this merged in Yarn 1, as many of us still use it.
Issue
Solutions
Solution 1 : Modify execute-lifecycle-script.js
This would be the most ideal IMO, assuming there are no side-effects.
A simple change is to edit
makeEnv
to the following:Solution 2 : Modify cmd files
We can resolve symlinks in the generated command files.
Here is an example:
We'd want to ensure that this works with Win XP and up, but I believe it will.
If not, we can also do something more simple, like using cd to the path.
Questions for the Yarn Team
Questions I'd have for the Yarn team are:
a. Would it be better to just use realpath at a higher level?
b. Is there any potential downside to modifying it here?
Failing tests
Looks like I'm getting some failures:
This seems to be happening locally and on the latest master (before my changes) as well. Not sure what's going on here, as that package exists on npmjs registry, but if anyone has any guidance, I'm happy to make adjustments to ensure all passes.