feat: add package dependents list page#2208
feat: add package dependents list page#2208thealxlabs wants to merge 7 commits intonpmx-dev:mainfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
📝 WalkthroughWalkthroughAdds a new "Dependents" page at app/pages/package/[[org]]/[name]/dependents.vue that fetches paginated dependents from a new cached API endpoint server/api/registry/dependents/[...pkg].get.ts (queries the npm registry search API). Extends Package Header (app/components/Package/Header.vue) to accept Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (3)
test/unit/app/server/dependents.spec.ts (1)
92-110: Consider testing the actual API handler instead of duplicating mapping logic.The tests define a local
mapNpmSearchResponsefunction that mirrors the production code. If the production logic changes, these tests won't catch regressions. Consider importing or invoking the actual handler to ensure tests remain coupled to production behaviour.app/pages/package/[[org]]/[name]/dependents.vue (2)
166-179: Inconsistent icon placement between pagination buttons.The "Previous" button uses
classiconprop for the icon, whilst the "Next" button uses an inline<span>element. Consider using the same approach for both buttons for consistency.♻️ Proposed fix for consistent button styling
- <ButtonBase variant="secondary" :disabled="page >= totalPages - 1" `@click`="nextPage"> + <ButtonBase + variant="secondary" + :disabled="page >= totalPages - 1" + `@click`="nextPage" + icon-position="end" + > {{ $t('common.next') }} - <span class="i-lucide:chevron-right w-4 h-4" aria-hidden="true" /> + <template `#icon`> + <span class="i-lucide:chevron-right" aria-hidden="true" /> + </template> </ButtonBase>Alternatively, verify if
ButtonBasesupportsclassiconwith right-side positioning, similar to the left chevron pattern.
84-87: Consider using i18n for SEO metadata.The SEO title and description use hardcoded English strings. For consistency with other localised content, consider using translation keys, though SEO metadata often intentionally uses specific formats for search engine optimisation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1c79f601-4587-4965-9ff4-0be29bc445fc
📒 Files selected for processing (5)
app/components/Package/Header.vueapp/pages/package/[[org]]/[name]/dependents.vuei18n/schema.jsonserver/api/registry/dependents/[...pkg].get.tstest/unit/app/server/dependents.spec.ts
| try { | ||
| const data = await $fetch<NpmSearchResult>(NPM_SEARCH_BASE, { | ||
| query: { | ||
| text: `dependencies:${packageName}`, | ||
| size, | ||
| from, | ||
| }, | ||
| }) |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
npm registry search API sort by popularity or downloads
💡 Result:
Yes, the npm registry provides a search API endpoint that supports sorting by popularity or downloads via weighted scoring factors. The endpoint is GET https://registry.npmjs.org/-/v1/search. Key query parameters for sorting: - text: the search query (required for searching) - size: number of results (default 20, max 250) - from: offset for pagination - quality: weight (0-1) for quality score - popularity: weight (0-1) for popularity score (based on downloads and other metrics) - maintenance: weight (0-1) for maintenance score To sort primarily by popularity, set popularity=1.0&quality=0&maintenance=0. Results are scored as a weighted combination, normalized as a unit vector. Example to get top 10 results for "react" sorted by popularity: curl "https://registry.npmjs.org/-/v1/search?text=react&size=10&popularity=1.0&quality=0&maintenance=0" Each result includes a "score" object with final score and detail breakdown (quality, popularity, maintenance), plus searchScore for text relevance. This is the official public API, actively used by libraries like libnpmsearch (npm/npm/libnpmsearch), which passes these opts directly to the endpoint. Popularity incorporates download stats and other factors. Note: No direct "sort=downloads" parameter; use popularity weighting. For exact download counts, use separate /downloads/point endpoints, but not for search sorting.
Citations:
- 1: https://github.com/npm/registry/blob/main/docs/REGISTRY-API.md
- 2: https://stackoverflow.com/questions/34071621/query-npmjs-registry-via-api
- 3: https://www.npmjs.com/package/libnpmsearch
- 4: https://github.com/npm/libnpmsearch
- 5: https://www.edoardoscibona.com/exploring-the-npm-registry-api
🏁 Script executed:
# First, locate and examine the file
find . -name "[...pkg].get.ts" -o -name "*dependents*" -type f | head -20Repository: npmx-dev/npmx.dev
Length of output: 152
🏁 Script executed:
# Let's search for the specific file pattern
fd "dependents.*pkg" --type fRepository: npmx-dev/npmx.dev
Length of output: 43
🏁 Script executed:
# Search for the file in api registry directory
fd -t f "pkg" server/api/registry/dependents/Repository: npmx-dev/npmx.dev
Length of output: 107
🏁 Script executed:
# Try a broader search
git ls-files | grep -i dependentsRepository: npmx-dev/npmx.dev
Length of output: 195
🏁 Script executed:
cat -n server/api/registry/dependents/\[...\pkg\].get.tsRepository: npmx-dev/npmx.dev
Length of output: 2768
Add popularity weighting to npm search query to sort dependents by download count.
The current implementation passes only text, size, and from parameters to the npm search API, which returns results sorted by relevance. PR objective #31 requires sorting by download count. The npm search API supports popularity weighting via the popularity parameter (0–1 scale, based on downloads). To prioritise downloads, add popularity: 1.0, quality: 0, maintenance: 0 to the query object (lines 50–54).
| getKey: event => { | ||
| const pkg = getRouterParam(event, 'pkg') ?? '' | ||
| const query = getQuery(event) | ||
| return `dependents:v1:${pkg}:p${query.page ?? 0}:s${query.size ?? 20}` |
There was a problem hiding this comment.
Cache key may not match decoded package name.
The cache key uses the raw route param getRouterParam(event, 'pkg'), but the handler decodes the package name with decodeURIComponent(rawName) on line 37. For URL-encoded package names (e.g., %40scope%2Fpkg), the cache key and actual query could diverge, causing unnecessary cache misses or stale entries.
🔧 Proposed fix to use decoded package name in cache key
getKey: event => {
const pkg = getRouterParam(event, 'pkg') ?? ''
+ const decodedPkg = decodeURIComponent(pkg)
const query = getQuery(event)
- return `dependents:v1:${pkg}:p${query.page ?? 0}:s${query.size ?? 20}`
+ return `dependents:v1:${decodedPkg}:p${query.page ?? 0}:s${query.size ?? 20}`
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| getKey: event => { | |
| const pkg = getRouterParam(event, 'pkg') ?? '' | |
| const query = getQuery(event) | |
| return `dependents:v1:${pkg}:p${query.page ?? 0}:s${query.size ?? 20}` | |
| getKey: event => { | |
| const pkg = getRouterParam(event, 'pkg') ?? '' | |
| const decodedPkg = decodeURIComponent(pkg) | |
| const query = getQuery(event) | |
| return `dependents:v1:${decodedPkg}:p${query.page ?? 0}:s${query.size ?? 20}` | |
| }, |
Lunaria Status Overview🌕 This pull request will trigger status changes. Learn moreBy default, every PR changing files present in the Lunaria configuration's You can change this by adding one of the keywords present in the Tracked Files
Warnings reference
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
howwohmm
left a comment
howwohmm
left a comment
There was a problem hiding this comment.
good feature — fills a real gap. a few issues from the full diff:
-
silent error masking in the API route. the catch block (line ~72) returns
{ total: 0, packages: [] }for all errors — 429 rate limits, 500s, network timeouts all become "no dependents found." the client error state will never trigger sinceuseLazyFetchsees a valid 200. the user sees the empty state instead of an error. consider re-throwing non-404 errors so the client can surface the error state. -
displayVersiontype mismatch. independents.vue, you passpkg.value?.requestedVersion(astring) asdisplay-version, butPackageHeadertypes it asPackumentVersion | null. this will cause a TS error and runtime issues if the header accesses.fundingor other version object fields. -
npm search
totalis an estimate. for popular packages, the real dependent count is often 10-100x higher than what npm search returns. consider adding "(approximate)" next to the count, or noting the data source. -
tests re-implement the mapping logic rather than importing the actual handler. if the server logic diverges, the tests won't catch it. the timeline PR (#2245) imports the handler directly — worth aligning.
the provenance touch target fix (py-1.25 → py-1.5) is unrelated — might be cleaner as a separate commit.
howwohmm
left a comment
howwohmm
left a comment
There was a problem hiding this comment.
correction on point 2 from my earlier review — requestedVersion is typed as SlimPackumentVersion | null (which extends PackumentVersion), not a string. so the displayVersion prop is type-safe. apologies for the false flag.
points 1 (silent error masking in the API route), 3 (npm search total is approximate), and 4 (tests re-implementing mapping logic) still hold.
2 participants
🔗 Linked issue
resolves #1987
resolves #31
🧭 Context
There was no way to browse which packages depend on a given npm package from within npmx.dev. This is a commonly requested feature that npm.js itself surfaces.
📚 Description
/package/:name/dependentspage (app/pages/package/[[org]]/[name]/dependents.vue) that lists packages depending on the viewed package, with pagination.server/api/registry/dependents/[...pkg].get.ts) that queries the npm search API withdependencies:<name>and returns a paginated, simplified package list.app/components/Package/Header.vue).content-typeheader to detect binary file #2036 a11y header), i18n schema updates for the newpackage.dependentskeys andcommon.previous/common.next.A unit test (
test/unit/app/server/dependents.spec.ts) verifies the npm search response mapping logic including optional field fallbacks, pagination offset computation, and size capping.