refactor: add proper route segments for package code

[essenmitsosse]

This is the first step to get rid of the catch all segments in routing.

If this looks good and we want to continue like this, I would like to change all routes to be properly described. Once they are all converted, a lot of the manual path splitting and build code can disappear and we can just pass around the route objects which should remove a lot of boiler plate code. It also will improve typing.

This also "fixes" the escaping of the slash in package names with an org.

[vercel]

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

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

2 Skipped Deployments

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

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

This PR replaces the array-based basePath: string[] prop with a named-route prop baseRoute: Pick<RouteNamedMap['code'], 'params'> across DirectoryListing, FileTree, MobileTreeDrawer and related components, and updates InstallScripts and package pages to build RouteLocationRaw objects using params (org, packageName, version, filePath). The package-code page route is adjusted to accept optional org scope and a catch-all filePath; route builders and URL helpers are refactored to use route.params directly.

Possibly related PRs

• refactor: use object-syntax/named routes #1041: Modifies the same code-routing helpers and Code component routing props; appears to be an earlier or parallel refactor of the same surfaces.
• fix: set org to empty string to make sure its route param is omitted #1126: Alters construction and handling of route params (notably org) used when building RouteLocationRaw navigation targets.

Suggested reviewers

• danielroe

🚥 Pre-merge checks | ✅ 1

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description check	✅ Passed	The PR description clearly relates to the changeset, describing a refactoring to replace catch-all routing segments with properly described route segments and addressing scoped package name escaping.

_{✏️ 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

---

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

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (1)

app/pages/package/[[org]]/[name].vue (1)

519-533: Avoid non‑null assertions when splitting package names.

The split array indices are asserted with !. Prefer explicit guards to keep index access type‑safe and avoid unexpected runtime issues when the name is malformed.
As per coding guidelines, "Ensure you write strictly type-safe code, for example by ensuring you always check when accessing an array value by index".

♻️ Suggested refactor

-const linkCode = computed((): Parameters<typeof navigateTo>[0] | null => {
-  if (pkg.value == null || resolvedVersion.value == null) {
-    return null
-  }
-  const split = pkg.value.name.split('/')
-  return {
-    name: 'code',
-    params: {
-      org: split.length === 2 ? split[0]?.replace(/^@/, '') : undefined,
-      packageName: split.length === 2 ? split[1]! : split[0]!,
-      version: resolvedVersion.value,
-      filePath: '',
-    },
-  }
-})
+const linkCode = computed((): Parameters<typeof navigateTo>[0] | null => {
+  if (pkg.value == null || resolvedVersion.value == null) return null
+
+  const [first, second] = pkg.value.name.split('/')
+  const isScoped = pkg.value.name.startsWith('@') && !!second
+  const packageName = isScoped ? second : first
+  if (!packageName) return null
+
+  return {
+    name: 'code',
+    params: {
+      org: isScoped ? first.replace(/^@/, '') : undefined,
+      packageName,
+      version: resolvedVersion.value,
+      filePath: '',
+    },
+  }
+})

[danielroe]

this is absolutely something we should be doing - would you check the failing CI?

[codecov]

Codecov Report

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

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

📢 Thoughts on this report? Let us know!

[essenmitsosse]

Ok, so unfortunately there is no elegant way to enforce the @ for the org while having the segment optional, but we can just make it entirely optional, without enforcing the @ which is still an improvement over before.

@danielroe should be fine now.

[coderabbitai]

Actionable comments posted: 3

[danielroe]

seems like a couple of good comments from @coderabbitai 🙏

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@danielroe Thank you! Happy to help with the review. Let me know if you need anything else as this PR progresses. 🚀

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@danielroe Thank you for the kind words! 🙏 I'm happy to help ensure the refactoring is solid. If you have any questions about my comments or need clarification on any of the suggestions, feel free to ask!

(ﾉ◕ヮ◕)ﾉ*:･ﾟ✧ 🐰

[coderabbitai]

Actionable comments posted: 1

[danielroe]

there may be some patterns here: #158 (comment)

[essenmitsosse]

@danielroe should I try to make this work before? Behavior and types are working fine now. We just lack the enforcement of the @ which only means invalid path we will in package resolution not on the Vue router level. Which isn't ideal but also not really a problem.

[essenmitsosse]

@danielroe should all be fine now. My suggestion would be to merge this and I'll create an issue for the @ in org. I think it's a nice-to-have, but nothing critical. I'd rather focus on getting all routes streamlined.