False positive dependent packages

[benmccann]

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]

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]

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]

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]

Absolutely! Done here: https://github.com/ecosyste-ms/packages/issues/796

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

[andrew]

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]

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]

@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]

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]

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.