fix: use fast-npm-meta in timeline

[43081j]

🔗 Linked issue

N/A

🧭 Context

Timeline is currently awfully slow for packages with a large amount of versions.

📚 Description

We were fetching the whole packument which is pretty big.

So this switches to using fast-npm-meta which is basically just
trimmed down metadata.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
npmx.dev	Ready	Preview, Comment	Apr 16, 2026 8:30am

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ignored	Preview	Apr 16, 2026 8:30am
npmx-lunaria	Ignored		Apr 16, 2026 8:30am

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• Refactor
  • Enhanced the efficiency of package version timeline and size data retrieval, improving query performance for version history information without affecting user-facing functionality.

Walkthrough

Updated package metadata retrieval in the timeline sizes API endpoint from fetchNpmPackage() to getVersions(), adjusting the logic to utilise the new return structure with versions and time fields whilst maintaining existing version enumeration, sorting and pagination functionality.

Changes

Cohort / File(s)	Summary
Package Metadata Retrieval server/api/registry/timeline/sizes/[...pkg].get.ts	Refactored to use getVersions() instead of fetchNpmPackage(). Updated version enumeration and time-based filtering to work with the new response structure containing versions and time fields. Pagination and size calculation logic remain unchanged.

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'fix: use fast-npm-meta in timeline' directly describes the main technical change made in the pull request - switching from fetching full packument to using fast-npm-meta for better performance.
Description check	✅ Passed	The description is directly related to the changeset. It explains the performance problem (slow timeline for packages with many versions), the current approach (fetching full packument), and the solution implemented (switching to fast-npm-meta for trimmed metadata).

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch jg/faster-clocks

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[coderabbitai]

🧹 Nitpick comments (1)

server/api/registry/timeline/sizes/[...pkg].get.ts (1)

46-48: Precompute publish timestamps before sorting.

Date.parse is currently executed repeatedly during sort comparisons. For large version lists, precomputing once per version is cheaper and removes the need for non-null assertions.

♻️ Proposed refactor

-      const allVersions = versions
-        .filter(v => time[v])
-        .sort((a, b) => Date.parse(time[b]!) - Date.parse(time[a]!))
+      const allVersions = versions
+        .map(version => ({
+          version,
+          publishedTs: Date.parse(time[version] ?? ''),
+        }))
+        .filter(item => Number.isFinite(item.publishedTs))
+        .sort((a, b) => b.publishedTs - a.publishedTs)
+        .map(item => item.version)

As per coding guidelines, "Follow standard TypeScript conventions and best practices" and "Ensure you write strictly type-safe code".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/api/registry/timeline/sizes/`[...pkg].get.ts around lines 46 - 48, The
sort repeatedly calls Date.parse and uses non-null assertions on time entries;
precompute a numeric timestamp map for each version from versions and use that
map when filtering and sorting (replace the inline Date.parse(time[...]) calls),
then sort by the numeric timestamps (e.g., compare tsMap[b] - tsMap[a]) and
remove the non-null assertions—update the code that builds allVersions (and any
uses of time within that scope) to reference the precomputed tsMap for
type-safe, single-parse sorting.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@server/api/registry/timeline/sizes/`[...pkg].get.ts:
- Around line 46-48: The sort repeatedly calls Date.parse and uses non-null
assertions on time entries; precompute a numeric timestamp map for each version
from versions and use that map when filtering and sorting (replace the inline
Date.parse(time[...]) calls), then sort by the numeric timestamps (e.g., compare
tsMap[b] - tsMap[a]) and remove the non-null assertions—update the code that
builds allVersions (and any uses of time within that scope) to reference the
precomputed tsMap for type-safe, single-parse sorting.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 23554948-7402-4426-8818-2b42739ab8cf

📥 Commits

Reviewing files that changed from the base of the PR and between 75bce20 and 700454c.

📒 Files selected for processing (1)

• server/api/registry/timeline/sizes/[...pkg].get.ts

[graphieros]

:)