-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix yarn lockfile with unknown resolvers #345
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
louislang
previously approved these changes
May 4, 2022
matt-phylum
previously approved these changes
May 4, 2022
kylewillmon
requested changes
May 4, 2022
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At a minimum, I think we need to print a warning for any packages that we ignore.
I've put additional concerns on the related issue (#344)
kylewillmon
previously approved these changes
May 5, 2022
kylewillmon
reviewed
May 5, 2022
The yarn lockfile allows various different resolvers other than the standard one which pulls from npm. Some of these include the filesystem (@workspace), http/s (@http/s), and ssh (@ssh). To ensure our parser is robust against all types of possible resolvers, this patch checks for the presence of `@npm` to ensure that the dependency can be resolved through npm. All other dependencies are silently ignored. This comes with the trade-off that it is easier for a failure to parse a dependency, that can be resolved through npm, to be hidden from the user, opening up the possibility for hidden vulnerabilities. It also assumes that no package scope starts with `@npm`, otherwise the parser might throw an error. Closes #344.
This is a complete change in how the yarn v2 parser parses the resolution field, which should hopefully both make the parser simpler and more error-resistent. Instead of complex splitting logic, the parser now makes use of the fact that dependencies inclued at most one `@` at the beginning of their name, thus clearly identifying the resolver as anything past the second `@`. The supported resolvers are now explicitly handled by checking the format of the resolution's resolver, an unrecognized resolver will cause an error.
kylewillmon
approved these changes
May 5, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The yarn lockfile allows various different resolvers other than the
standard one which pulls from npm. Some of these include the filesystem
(@workspace), http/s (@http/s), and ssh (@ssh).
To ensure our parser is robust against all types of possible resolvers,
this patch checks for the presence of
@npm
to ensure that thedependency can be resolved through npm. All other dependencies are
silently ignored.
This comes with the trade-off that it is easier for a failure to parse a
dependency, that can be resolved through npm, to be hidden from the
user, opening up the possibility for hidden vulnerabilities. It also
assumes that no package scope starts with
@npm
, otherwise the parsermight throw an error.
Closes #344.