fix: update isr configuration for package pages

[alexdln]

🔗 Linked issue

Resolves #1530 resolves #1267 resolves #1266

Not fixes #1194 #1534 #1558

🧭 Context

• Version pages almost always displayed a 500 - server error as the title;
• Version pages often failed to load, with a redirect to segmentPath in half the cases;
• In many cases, the readme didn't appear, or the content disappeared after hydration.

From the initial research:

• Server always sees the wrong path for version pages. But sometimes it returns a blank page, and once on the client, it manages to work correctly and displays the page as expected
• Sometimes it redirects immediately, apparently on the client. That is, the request path is correct, but the response immediately shows that the path is segmented, not injected parameters
• Definitely server routing issue. But when there's a trailingSlash at the end of the path, the problem doesn't reproduce (https://npmxdev-git-fork-alexdln-chore-test-route-overriting-npmx.vercel.app/package/obsidium/v/3.1.0/)
• But if we enable trailingSlash in the vercel settings, then for versions it will always redirect to a page without it (?!)
• It seems to redirect when we request for the version failed for some reason (f.e. rate limit). That is, if our request failed, we get a server error and a redirect. And if it somehow went through, we get a blank page from server, since the [name] package doesn't exist and then we trying to load it client-side

📚 Description

• Rewrote the version loading logic, as the previous variant often lost data from server and failed to load on the client;
• Updated isr settings in nuxt.config for package paths to match all subpaths and disabled fallback

🤞🤞🤞

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
npmx.dev	Ready	Preview, Comment	Feb 24, 2026 9:53am

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ignored	Preview	Feb 24, 2026 9:53am
npmx-lunaria	Ignored		Feb 24, 2026 9:53am

[codecov]

Codecov Report

❌ Patch coverage is 0% with 11 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
app/composables/npm/useResolvedVersion.ts	0.00%	8 Missing and 2 partials ⚠️
app/pages/package/[[org]]/[name].vue	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR changes three areas: the useResolvedVersion composable now uses useAsyncData and performs an explicit $fetch, returning the resolved version or null; the package page app/pages/package/[[org]]/[name].vue replaces status-code-based error handling with a direct null check on resolvedVersion (throwing a 404 when null); and nuxt.config.ts consolidates multiple ISR package routes into a single catch-all /package/** (preserving the corresponding _payload.json route).

Possibly related PRs

• fix: provide payload fallback json #1186: Modifies ISR routing and payload fallback configuration for package routes, directly overlapping the nuxt.config.ts changes.

Suggested reviewers

• danielroe

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The code changes address the linked issues: rewriting version loading logic preserves server-rendered content and prevents hydration mismatches (#1558); fixing null resolvedVersion handling prevents 500 error titles (#1530, #1266); updating ISR routes ensures reliable version-specific package resolution (#1534); ISR configuration changes prevent blank layout loads (#1267); disabling fallback stabilises behaviour under upstream failures (#1194).
Out of Scope Changes check	✅ Passed	All changes are within scope: useResolvedVersion composable rewrite, error handling consolidation in package page component, and ISR configuration updates for package routes directly address the linked issues.
Description check	✅ Passed	The PR description clearly describes the changeset: version loading logic was rewritten, ISR settings were updated, and specific issues with server routing and hydration mismatches were addressed.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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.}

[coderabbitai]

Actionable comments posted: 1

---

ℹ️ Review info

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c9e9821 and f6df068.

📒 Files selected for processing (3)

• app/composables/npm/useResolvedVersion.ts
• app/pages/package/[[org]]/[name].vue
• nuxt.config.ts

[serhalp]

This looks good to me, but seems like a defer-to-Daniel type of PR 😁

Thank you so much for digging into this gnarly issue! 🙌🏼

[alexdln]

Thanks

checking a few more options

[alexdln]

Main remaining problem:

The server builds the page, but when the payload is loaded during hydration, it is empty and the user receives an error

Well, all tested options work poorly

1. If we leave the fallback, it works separately for HTML and JSON, which causes artifacts. It also returns content for everyone at once, which is bad for SEO, since we'll have millions of pages with identical, empty content
2. If we remove it, the pages take a very long time to load and you can often really feel it
3. If we remove ISR, we will receive more requests to our servers and overall it will not be fast
4. We can make eome parts clientOnly, but it seems that this will only speed up by sth like 20 percent
5. If we try to track what's in our payload and make requests if it's empty, we'll be formally doing double work and risking to recieve other artifacts

It could be improved if Nuxt had a more reliable mechanism for synchronizing HTML and payload (store it inside HTML and don't re-request on direct visit?). But this would leave a SEO problem
It would be good to have sth like cacheComponents so that the page could be served immediately, and the content would be rendered in the background and then cached and returned, but anyway problems for cold start

So, we either need a completely custom server or disable fallback and accept the site's slow performance.

---

For now, I've kept minimal changes to address some of the issues