Skip to content

Conversation

@remypar5
Copy link

What's the problem this PR addresses?

Allowing users to specify a version or range for yarn why to find out why a specific version appears in the dependency tree. This is particularly useful if you want to address CVEs.

Closes #6859

How did you fix it?

  • Check if a version/range is specified and handling it accordingly
  • For both simple and recursive mode

Checklist

  • I have set the packages that need to be released for my changes to be effective.
  • I will check that all automated PR checks pass before the PR gets reviewed.

@remypar5
Copy link
Author

@arcanis are you available to review this? You refactored yarn why some time ago

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do not use the release-date package name here. They have release time information attached to them at the package server level to test related features (e.g. npmMinimalAgeGate). Using that name here is just confusing. Reuse/create one of the generic ones like one-fixed-dep.

`Explain why version 3.3.1 of lodash is in your project`,
`$0 why [email protected]`,
], [
`or why version 3.X of lodash is in your project`,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`or why version 3.X of lodash is in your project`,
`Explain why version 3.x of lodash is in your project`,

Comment on lines +70 to +72
function isSameIdent(pkg: Ident, targetPkg: Ident) {
return pkg.identHash === targetPkg.identHash;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function already exists as structUtils.areIdentsEqual. But honestly, I think just inlining this is much more readable

if (!isSameIdent(nextPkg, targetPkg))
continue;

if (!structUtils.isPackageInRange(nextPkg, targetPkg.range))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This only works for semver ranges, right? What happens if the given descriptor's range is non-semver? Either way, I think that should fail-fast above, when parsing the descriptor.

seen.add(pkg.locatorHash);

if (pkg.identHash === identHash) {
if (isSameIdent(pkg, targetPkg)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can just can in-range-ness here and eliminate the checks below? Or is there an edge case I am not considering?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature] yarn why for specific package version

2 participants