-
Notifications
You must be signed in to change notification settings - Fork 2.4k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Vulnerability remediation using Yarn resolutions #3093
Comments
Hi! I can say "yes" to both :) |
Thanks. I guess then the downside of this approach is that potentially this new version (i.e. |
Woops - didn't see that before 🤔 Yes, although there is a potential problem because it'll also force packages that are, for example, |
This comment was marked as off-topic.
This comment was marked as off-topic.
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Assume that:
thepackage
withinyarn.lock
1.8.5
)Can we "resolve" this vulnerability in all cases by simply adding it as a
resolutions
entry?And should it be written just like this?
Would the above achieve the following dual aims?
< 1.8.5
versions even if some dependencies/sub-dependencies depend on versions in that range@arcanis could you clarify if this is a good approach to vulnerability remediation of transitive Yarn.lock dependencies?
The text was updated successfully, but these errors were encountered: