Skip to content
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

False positive dependent packages #794

Open
benmccann opened this issue Jun 22, 2024 · 9 comments
Open

False positive dependent packages #794

benmccann opened this issue Jun 22, 2024 · 9 comments
Assignees
Labels
bug Something isn't working

Comments

@benmccann
Copy link

https://packages.ecosyste.ms/registries/npmjs.org/packages/deep-equal/dependent_packages?order=desc&sort=downloads seems to just be showing anything with the string deep-equal and so it's getting lots of false positives containing fast-deep-equal

@andrew andrew self-assigned this Jun 22, 2024
@andrew andrew added the bug Something isn't working label Jun 22, 2024
@andrew
Copy link
Member

andrew commented Jun 22, 2024

I suspect what's happening here is that many of those packages have older versions that have dependencies on deep-equal that have since been removed or swapped to fast-deep-equal in later versions, for example: https://packages.ecosyste.ms/registries/npmjs.org/packages/fast-deep-equal/versions/1.0.0

There's a flag in the API to only dependent packages that still use the dependency in the latest version, but it's not currently used in the web UI, could potentially add a toggle in there too.

@benmccann
Copy link
Author

Ah, that would be great. The other thing I'd really love an option for in the web UI, if it's available in the API, is the ability to filter for just where it shows up in dependencies and not in devDependencies in the package.json

@andrew
Copy link
Member

andrew commented Jun 23, 2024

Ah, that would be great. The other thing I'd really love an option for in the web UI, if it's available in the API, is the ability to filter for just where it shows up in dependencies and not in devDependencies in the package.json

@benmccann would you be able to open that feature request as a separate issue so it doesn’t get lost here, I think that feature will be quite easy to implement

@benmccann
Copy link
Author

Absolutely! Done here: #796

Thanks so much for providing this service. It's if great use to the ecosystem!

@andrew
Copy link
Member

andrew commented Jun 24, 2024

I've added a latest parameter to the web view, you can see it in action here: https://packages.ecosyste.ms/registries/npmjs.org/packages/deep-equal/dependent_packages?latest=true

Just need to add a option for toggling it to the sidebar of that page.

@benmccann
Copy link
Author

benmccann commented Jun 24, 2024

That's great. Thanks!!

I wonder if it should be the default. What's the use case for finding packages that used to be dependants, but no longer are?

@andrew
Copy link
Member

andrew commented Jun 24, 2024

@benmccann yeah you're probably correct, the main use I have for the "no longer using" packages are when looking for dependents of packages with security issues I want to see everything, including older versions.

@andrew
Copy link
Member

andrew commented Jun 24, 2024

Screenshot 2024-06-24 at 15 44 14

Just deployed that now, you might need to force refresh your browser to pick it up, I've also defaulted the web ui to show the latest with latest=false showing everything. I'll leave the API as it to avoid making a breaking change.

@dominikg
Copy link

the latest parameter seems to not match semver ranges, eg

https://packages.ecosyste.ms/registries/npmjs.org/packages/tsconfck/dependent_packages?kind=runtime&sort=downloads&order=desc&latest=true doesn't list most dependents. I did publish a new patch this week and not many lockfiles have been updated i think. But their semver ranges do include the new patch.

compare to:
https://packages.ecosyste.ms/registries/npmjs.org/packages/tsconfck/dependent_packages?kind=runtime&sort=downloads&order=desc&latest=false (note oclif/caml doesn't use it in its latest version).

not sure how to best solve this, but ideally you'd be able to ignore or match the semver range of package in dependants package.json depenencies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants