[yangshun]

Follow-up to #646: add route checking for plain URL strings, alongside untyped strings and destination objects. It's opt-in for existing apps and on by default for new apps.

// void.config.ts
export default defineConfig({
  routing: { typedRoutes: true },
});

With routing.typedRoutes on, URL strings in Link's href, router.visit(), router.prefetch(), router.flush() and c.rewrite() must match one of the app's routes. Each dynamic segment accepts any text, and a query string or hash may follow. Fixed segments can be written as is (/café menu) or percent-encoded, as routeUrl() returns them (/caf%C3%A9%20menu). Links may also point to same-page queries and hashes and to http://, https://, mailto: and tel: URLs. Relative paths are rejected. With the flag off, the types are unchanged.

<Link href="/about">About</Link>
<Link href={`/users/${user.id}?tab=activity`}>Profile</Link>
<Link href={routeUrl('/users/:id', { params: { id } })}>Profile</Link>
<Link href="/abuot">About</Link> // Type error
<Link href={post.path as RouteUrl}>{post.title}</Link>

void/routes exports two new types. Both are string when the flag is off:

• RouteUrl: the URL of one of the app's routes. routeUrl() returns it, and c.rewrite() accepts it.
• Href: anything a link can point to. It's RouteUrl, a same-page query or hash, or an external URL. Link's href and RouteUrlInput use it.

New apps. void init (and create-void, which runs it) writes routing: { typedRoutes: true } when it scaffolds a new Pages app. Running void init in an existing project leaves the setting unchanged.

Also in this PR:

• Runtime fix: query-only links such as ?page=2 and Link data merged into a #hash href now stay on the current page. Before, they went to /?page=2. Relative URLs now resolve against the current page instead of the origin, in the shared router, the React client and all four Link click handlers.
• Route coverage:
  • Route files with only a default export count as routes.
  • A trailing /* also accepts its bare prefix (/docs/* accepts /docs), as Hono does.
• Vue Link types: it now declares the anchor and button attributes and listeners it passes through (target, download, @click, …). They were rejected under strict template checking even with the flag off.

Notes for review:

• How the switch works: the generated .void/routes.d.ts turns the check on through a RouteTypesConfig interface, the same augmentation pattern as RoutePathMap. Encoded spellings come from a generated EncodedRoutePathMap. Both work whether void/routes resolves to the generated file or to the package.
• RewriteDestination is unchanged. routing.rewrites and routing.fallbacks destinations can contain :splat placeholders and static files. Only c.rewrite()'s parameter narrows.
• Vue Link cast: the exported type is DefineSetupFnComponent<LinkProps>. The options component isn't assignable to it, so it keeps a cast. A compile-time check next to the props fails if the written-out props drift from the runtime ones. It can't live in a test, because isolatedDeclarations prevents exporting the runtime props.
• Known type limits:
  • A dynamic segment also matches empty or /-leading text, so with a root dynamic page //example.com passes. Excluding that would need per-character unions. It's documented and pinned by a fixture.
  • Only uppercase percent-encoding, as routeUrl() writes it, is accepted.
• void.config.ts isn't watched in dev, so changing the flag needs a dev restart or void prepare. The docs say so.
• Svelte Link.svelte isn't template-checked, since the repo has no svelte-check. Its props type lives in link-props.ts, which the fixtures check.

Validation:

• vp run check: 33/33 tasks passed.
• Type fixtures with the flag on cover the generated declarations, the package declarations, and the package types alone, plus Link href in all four adapters. Every new case was confirmed to fail against the previous behaviour.
• The four adapter integration suites pass (183 tests), including a new browser case for query-only Link navigation.
• The packed-consumer smoke test (pnpm, all four frameworks) asserts that void init turns on the flag. Its build and typecheck then run with checked routes.
• vp run test --base origin/main (before the last two commits): 15,501 passed. The 1 failure was a 5s timeout in plugin-cloudflare-v2.test.ts under load, and it passes on its own. The later commits were verified with their focused suites, vp run check and the packed checks.

[cpojer]

Awesome. imho this is clearly a better default. I don't really see any downsides to making this the default besides that it's a breaking change. What do you think about turning this on for all new projects created via void init?

One issue: Vue Link now rejects existing native attributes and events because the new props type for Vue omits them and it causes some issues with strictTemplates enabled in Vue (This usage now fails: <Link href="/" target="_blank" @click="handler">Home</Link>). Can you fix that?

[yangshun]

Ya I'm still reviewing, not ready for review yet oops. Yes we can turn it on. Do it while it's still early.

…

On Mon, 2 Nov 2026, 3:23 pm Christoph Nakazawa, ***@***.***> wrote: *cpojer* left a comment (voidzero-dev/void#662) <#662 (comment)> Awesome. imho this is clearly a better default. I don't really see any downsides to making this the default besides that it's a breaking change. What do you think about turning this on for all new projects created via void init? One issue: Vue Link now rejects existing native attributes and events because the new props type for Vue omits them and it causes some issues with strictTemplates enabled in Vue (This usage now fails: <Link href="/" target="_blank" @click="handler">Home</Link>). Can you fix that? — Reply to this email directly, view it on GitHub <#662?email_source=notifications&email_token=AAKBCHKFZXPCCVGJNRV7BDL5XAZAXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNJXGE2DSNZQGM22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-6571497035>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKBCHP2C6ZHDLOJIY3JGO35XAZAXAVCNFSNUABGKJSXA33TNF2G64TZHMYTCNRUGQZTOMBYGA5US43TOVSTWNRRGU3TSNRWGA3TNILWAI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[yangshun]

Feel free to make any docs changes

[cpojer]

Dude you are killing me requesting a review and then moving it back to draft :P

[yangshun]

Dude you are killing me requesting a review and then moving it back to draft :P

Yes I'm sorry for that, spotted some other things that I wanted changed. Take your time, don't need to review so fast haha.

[cpojer]

We move fast here! This is awesome, thanks for making this change.

We should maybe consider adding a feature to void migrate to enable this, but it's probably way too much work having to parse the JS and insert it in the right spot etc. to be worth it. Most Void apps haven't even been created yet!

[yangshun]

Ya. I actually think it's ok to make it the default. It's a breaking change, but it flags a real error and people should fix it. WDYT?

[cpojer]

We are trying to be careful about breaking changes as we want to provide a stable platform that people can depend on.

In a way what we just did is similar to Cloudflare's compatibility date - new projects get the new default automatically. I think that's fine for now.