Repository navigation
Add package dependents/dependees list to package detail view #1987
Description
Problem
When browsing a package on npmx.dev, there's no way to see which other packages depend on it. This is critical information for:
- Package maintainers assessing impact of breaking changes
- Users evaluating how widely adopted a package is
- Contributors deciding whether to submit PRs to a package
npmjs.com shows this under "Dependents" (e.g., searching depends:react shows 50k+ packages). npmx.dev has no equivalent feature.
Why it matters
A package with 10k dependents is a critical ecosystem dependency; breaking changes need careful review. A package with 3 dependents is lower risk. This distinction affects decision-making but is invisible in npmx.dev today.
Current behavior
The package detail page (src/routes/package/+page.svelte) displays README, versions, dependencies, downloads, and vulnerabilities. There is no section showing reverse dependencies.
Proposed behavior
Add a "Dependents" section below the dependencies list:
- Show count of packages that depend on this package
- Display top 10-20 dependents by download volume as a scrollable list
- Link each dependent to its npmx.dev package page
- Include a "View all dependents" link to a filtered search results page
- Cache the count (updates weekly, similar to download stats) since computing this on-demand would be expensive
Example
When viewing lodash, show:
Dependents (156,234 packages)
1. react - 50.2M weekly downloads
2. @babel/core - 28.1M weekly downloads
3. webpack - 22.3M weekly downloads
...
[View all 156,234 dependents]
Implementation notes
- npm registry API provides a dependents endpoint (similar to how downloads are fetched)
- The UI should follow existing patterns in
src/components/PackageCard.sveltefor displaying package lists - Consider lazy-loading the dependents list to avoid slowing page load
- The count should appear prominently in the package header (next to "Downloads") for quick scanning
Related
Related to #1984 (which addresses vulnerability surfacing) — this feature helps contextualize the risk level of any vulnerabilities found.
Contributed by Klement Gunndu
Activity
KlementMultiverse commentedon Mar 9, 2026
Withdrawing this issue. Apologies for any inconvenience.
ghostdevv commentedon Mar 23, 2026
How come? @KlementMultiverse
ehs5 commentedon Apr 8, 2026
Hi,
Shouldn't this be reopened - clearly seems like a feature that should be added?
mootari commentedon Apr 14, 2026
Perhaps because the information isn't trivially available. As far as I'm aware no API exists, which means this project would have to build and maintain the index itself.
See e.g. https://github.com/nice-registry/dependent-packages
Edit: The PR description claims there's an endpoint, but that one's been gone since late 2018.
ehs5 commentedon Apr 14, 2026
@mootari I came to the same conclusion after looking into it right after I posted my last message on here. Wanted to see if this issue was something I could quickly tackle, but I noped out of it pretty quickly. 😀
From what I can gather, npmjs.com is doing some heavy backend voodoo to make their dependents list.
@serhalp @danielroe FYI
mootari commentedon Apr 14, 2026
The dependents count could potentially be scraped from npmjs.com. Exposing the actual list of dependents though is a double edged sword, because it makes it easier for attackers to identify vulnerable packages.
Then there are nuances like target version etc. I'm also not sure how valuable it is to reproduce the excerpt that npmjs.com exposes, considering it seems to show only new packages.
rektide commentedon Apr 14, 2026
I looked at scraping, but there is a cloudflare guard. There's some advanced packages to have less chance of getting blocked, but tge most promising one I found https://github.com/sqdshguy/wreq-js (imho) requires a node-addon, which would make it not hostable on vercel.
I tend to think this would require hosting a package index.
My other thought is perhaps someone could build this reverse index as a service, ideally in a way where the static dataset could be retrieved. I'm more than willing to accept stale data, for a day, for a week maybe.
ghostdevv commentedon Apr 14, 2026
We could get this from the data work we're doing in e18e, Anna's registry is working today and mine will be working in the future
https://e18e.dev/learn/cleanup.html#tip-finding-dependents-of-a-package
rektide commentedon Apr 27, 2026
@ghostdevv what are the dependencies here? This seems to require a couchdb server with user and password?
This seems like this isn't designed for a full production load, would require significant couchdb resources to host. Perhaps premature optimization but I tend towards thinking dependees should be precomputed.
ghostdevv commentedon May 11, 2026
It should work without one if you use the dependents view - another example is Roman's dependents website, check the network requests
It should be able to handle npmx fine, and given what Anna has said I imagine more - and for what I'm working on the API for that can definitely do it, just needs to cook some more 😄