perf: parallelize jsDelivr README fallback probes#2384
perf: parallelize jsDelivr README fallback probes#2384trivikr wants to merge 4 commits intonpmx-dev:mainfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe PR changes README fetching in server/utils/readme-loaders.ts to fetch candidate filenames in batches of three concurrently via Promise.all. fetchReadmeFromJsdelivr now returns the first successful body found per batch; non-OK responses and fetch errors yield null. A new internal buildReadmeFetchCandidates constructs candidate lists while avoiding duplicates when a specific readmeFilename is provided. resolvePackageReadmeSource first attempts the explicit readmeFilename alone, then falls back to the batched candidates. Tests were added/expanded to verify batching, concurrency behaviour and candidate ordering. No exported signatures changed. Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 1✅ 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 |
|
Also updated PR to fetch provided readme before starting the fallback batch in 72bb0b2 |
| const matchedReadme = responses.find((response): response is Response => response !== null) | ||
| if (matchedReadme) { | ||
| return await matchedReadme.text() | ||
| } |
There was a problem hiding this comment.
| const matchedReadme = responses.find((response): response is Response => response !== null) | |
| if (matchedReadme) { | |
| return await matchedReadme.text() | |
| } | |
| for (const response of responses) { | |
| const text = await response?.text() | |
| if (text) return text | |
| } |
I guess it's possible that the readme response is empty, so I wonder if you should do something like this 🤔
2 participants
🔗 Linked issue
N/A
🧭 Context
README fallback probing in
server/utils/readme-loaders.tswas strictly sequential. On cache misses, packages with missing or nonstandard README filenames could pay for several failed jsDelivr requests before the loader found the right file or gave up, which made worst-case README render time noticeably slower than necessary.📚 Description
This changes the jsDelivr README fallback path to reduce that long-tail latency while keeping the fallback behavior conservative.
readmeFilenamefirst when it exists.test/unit/server/utils/readme-loaders.spec.ts.